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.

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

// Shadow build folders
*-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 #*#

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).

• 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