## What to commit and what not to commit

Only commit files that are needed to build the project to the repository. Do not commit any kind of derived or generated files (object files, executables, libraries, debugging symbols, intellisense files, etc) or any personal settings files (.suo files generated by Visual Studio, .user files generated by QtCreator, etc). It is ok to commit external libraries (like dlls) that our project depends on and that we won’t be changing or building ourselves, but make sure they are in a commonly accepted and known location so that duplicates don’t get scattered throughout different directories. Also, do not commit large data files to the repository. Keep in mind that once something has been committed, there is no way to really delete it other than deleting the entire repository and creating a new one from scratch. An svn delete will make it so something doesn’t show up in the current version of the repository, but it will always be in the history (and thus taking up space on the hard drive) as long as that repository exists. Because of that, the size of a repository on the server’s hard drive can only grow and never shrinks.

### Setting up the global ignore list

Right click inside a folder in windows explorer and select TortoiseSVN→Settings. Select “General” on the left pane. Put all of the following patterns (or at least the ones that may apply in your case) into the “Global ignore pattern” box (separated by spaces). Note that the “comments” are there for explanation and should not be copied into the box. If you use a different client than TortoiseSVN, you may need to find out how that client handles it. Or, you can manually set up svn's global ignore list in its config file. For Linux, this is usually located at ~/.subversion/config. In Windows (Vista and later), it should be at C:\Users\<username>\AppData\Roaming\Subversion\config. Simply uncomment the line for the global-ignores property under the [miscellany] section.

// Compiler outputs
*.o *.a *.so *.exe *.out *.obj

// Hidden files, temporary files, etc
.* *~ *.swp *.bak *.log

// Visual Studio files
*.pdb *.idb *.ncb *.ilk *.suo *.user *.mine

// Java files
*.class

// QtCreator files
*.user* Makefile *.Debug *.Release

// doxygen
latex html Doxyfile

// Unnecessary folders
bin Bin obj Obj lib Lib debug Debug release Release ignore Ignore

*-build-*

// Mac OSX files
.DS_Store

// Unix files
*.rej

// Windows files
Thumbs.db thumbs.db

// Python files
*.pyc *.pyo

// Matlab files
*.asv *.mexw32

// LaTeX / BibTeX
*.aux *.blg *.bbl *.toc *.lof *.lot

// Video files
*.avi

// Other SVN recommended defaults
*.lo *.la #*#

Copy and paste the following code in your Subversion “config” file. <br> For example, on Windows 7 with user WiSAR, the location is: C:\Users\WiSAR\AppData\Roaming\Subversion

global-ignores = *.o *.a *.so *.exe *.out *.obj
.* *~ *.swp *.bak *.log
*.pdb *.idb *.ncb *.ilk *.suo *.user *.mine
*.class
*.user* Makefile *.Debug *.Release
latex html Doxyfile
bin Bin obj Obj lib Lib debug Debug release Release ignore Ignore
*-build-*
.DS_Store
*.rej
Thumbs.db thumbs.db
*.pyc *.pyo
*.asv *.mexw32
*.aux *.blg *.bbl *.toc *.lof *.lot
*.avi
*.lo *.la #*#

## Trunk, branches, and tags

### When to work from the trunk and when to work from a branch

The trunk is where active development takes place and contains the most current version of the project. Although it may have bugs and may be missing features, the trunk should always at least build without errors. DO NOT commit code that does not build to the trunk, as doing so will break the build for everyone else that updates from the trunk thereafter, thus interfering with their own work. In general, it is ok to work directly from the trunk for fairly small, quick projects that you will only need to commit once – when you are done and have verified that it works.

If you are starting a larger project or are making more drastic changes that may take some time, you should do it in your own branch and then merge it back into the trunk when it is complete. Also, experimental projects that may or may not end up being included in the trunk should be developed in their own branch. With a separate branch, you can feel free to commit whenever you would like to back up your code or track its history (even if the code doesn’t build).

### How to create and work from a branch

• Creating a branch

:To create a branch, simply svn copy the code you need into a new folder in the branches folder. Typically, you’ll be copying from the trunk.

• Keeping a branch in sync

:When working on your own branch, you should periodically merge any changes that have been made to the trunk into your branch. This prevents your branch and the trunk from drifting too far apart, which can cause major problems when it comes time to merge them back together. By merging updates to the trunk into your branch, you can ensure that your new code is still compatible with the core of the project.

:To merge the trunk into your branch, first make sure that your local copy of your branch matches the repository’s copy (by updating, committing, or reverting) so that you do not lose work if the merge fails. Then, right click on your branch’s top level folder and select TortoiseSVN→Merge. Leave the bullet on “Merge a range of revisions” and click next. Browse to or type the URL for the trunk in the URL to merge from box and leave the revision range box empty (to merge all changes that were made to the trunk). On the next screen, leave the merge depth set to “working copy” and click merge. You may need to manually resolve conflicting changes to files. Note that nothing in the repository will actually be changed until you commit your branch with its newly merged changes.

• Merging a branch back into the trunk

:Immediately before reintegrating a branch with the trunk, you should merge the trunk with your branch and make sure everything works as expected. This way, the only differences between your branch and the current trunk will be the changes you have made. Merging the branch back into the trunk is done in essentially the same manner as described in the previous paragraph, except that you should right click on the trunk’s root folder (you’ll need an up to date working copy of the trunk checked out) when starting the merge and select the “Reintegrate a branch” bullet in TortoiseSVN. If you are reintegrating your branch via the command line, make sure to specify the “–reintegrate” option for svn merge. Remember that this won’t actually change anything in the repository until you commit the trunk with the newly merged changes. Also note that once a branch has been reintegrated, it is no longer usable for development. You must destroy it and recreate it from the trunk to continue.

### When and how to create a tag

Tags are snapshots of “good” or “working” versions of the code. They often correspond to major and/or minor versions of the software. Basically, they are a way to make it easy to find a version of the code that you think you will need later. For instance, if you had code ready for an upcoming demo, you could tag it and then continue developing in the trunk without fear of not being able to find the working demo code later.

You create a tag in exactly the same way as you create a branch (see above), except that you place it in the “tags” folder instead of the “branches” folder. The only thing that makes a tag different from any other folder in the repository is how you treat it. Thus, you should not be actively developing things in the tags folder.