Advanced subversion techniques, what am I missing?

Question

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?

Answer 1

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/

Answer 2

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:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

etc.

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.

Answer 3

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.

Answer 4

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.