I started using SVN about 9 months ago and it's been a game changer to say the least. Although, I feel I'm still a bit lost. I feel like there is a lot more I need to take advantage of to really step up my application development.

For example

I would like to be able to quarantine any volatile/major changes into some kind of 'sub-repository' or something. I'm finding that major changes are impeding minor bug fixes that are quite urgent. How can I push one simple update without pushing incomplete or broken code?

  • 3
    You might want to consider using hg for your local branches (you can use it with svn just fine, check this)
    – OneOfOne
    Dec 14, 2010 at 18:14
  • Ha! You're missing mercurial.
    – Dexter
    Dec 14, 2010 at 22:21
  • 3
    "Advanced Subversion" sounds like an oxymoron. Use Git or Mercurial, if only locally.
    – Macneil
    Dec 15, 2010 at 15:54

4 Answers 4


To address your example, you have three possibilities to do that:

  1. You can commit single files. If you use an IDE for accessing the Repository, it has most likely a view, to select or unselect single files before committing. On the command-line you type svn commit file1 path1/file2 path2 to commit file1, path1/file2 and every change under path2.
  2. You can make different working copies. You work on your large feature in your standard working copy and get the information about the urgent bug. You can checkout your repository to a different directory and fix the bug in this second working copy. You may even check out only a subdirectory with the component where the bug occurs. After bugfix you can commit in your second working copy without committing your work on the big feature. EDIT: That way is also described in the answer of Anna Lear.
  3. You create a branch for the work on your feature. For that you use the copy command. If you use the standard-layout for your repository (directories with the projectname and subdirectories with the names trunk, tags and branches, trunk containing the project) you can use the svn-copy-command like follows to create the branch: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Now you can switch your working copy to the new location: svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X. If you switch in bugfixing mode you commit your actual changes, switch your working copy back to trunk, fix the bug and commit, and switch the working copy back to your feature-branch. If you are ready with developing the feature you can merge it back to the trunk.

For the simple case described you will usually use #1 (I use most often), sometimes #2. Working with branches (case #3) is more complicated (read more), but allows for more tricks. But branches matching your description of a subrepository.

Besides from your example I cannot say much. There are many things about Subversion, but I don't know what you already use and what you need for your project. For learning more about SVN the SVN-Book is a great resource: http://svnbook.red-bean.com/

  • 3
    The problem with approach #1 is that you can't always know beforehand that your new feature and the bug-fix won't both end up involving changes to the same files. For this reason, I'd recomend #2 (individual working copy for each feature or bug fix) or #3 (individual branch for each feature or bug fix). Branches have the advantagethat you can commit changes on a branch before the feature or bug fix is complete without affecting checkouts from the trunk (with separate working copies, all commits affect the trunk). Dec 14, 2010 at 17:47

You can check out code into different sandboxes instead of just taking one copy and making all your changes there.

So you could have a folder structure that goes something like this:



All of those could be checked out from the same location in your SVN, e.g. http://mysvnrepo/trunk.

This way you can commit from your bug fix sandbox without affecting feature development ones, although you'll need to run svn update from other sandboxes to get the changes committed for the bug fix.


Have you looked at Subversion Branches at all?

One common technique is to keep your Trunk stable, applying critical fixes as required. You then create a branch for each new significant piece of work. Developers working on that project check out the branch and commit to the branch. It does not affect the Trunk until you decide to merge the branch back to the main trunk as part of your final integration.

Another approach is to have a branch for a particular Release, to avoid any other work accidentally being done on the trunk causing issues. You can bug-fix the 'Release Branch' as required and then fold those fixes back to the trunk when ready.

Your developers can have multiple working copies checked out - the trunk and any branches - or can swap between the trunk and a particular branch with the svn switch command.

I do not recommend having lots of 'sandbox' working copies that you keep separately checkout as (a) this prohibits collaboration with others and (b) it will be too easy to accidentally commit not-working-yet changes to the main trunk.


The current size of my working copy is 10GB, with more than 50.000 files. I can have several copies for different branches, but it takes a while just to create the new copy!

When an urgent bug comes, I usually save all my changes in a patch, revert everything, work on the bug and commit, then apply the patch I saved... Much easier and quicker than getting a fresh working copy. If I would need to do this often, I would have two working copies: one for long-term changes, the other for bug fixes.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.