Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We've just moved to SVN from CVS. We have a small team and everyone checks in code on the trunk and we have never ever used branches for development.

We each have directories on a remote dev server with the codebase checked out. Each developer works on their own sandbox with an associated URL to pull up the app in a browser (something like the setup here: Trade-offs of local vs remote development workflows for a web development team).

I've decided that for my current project, I'll use a branch because it would span multiple releases. I've already cut a branch out, but I am using the same directory as the one originally checked out (i.e. for the trunk).

Since it's the same directory (or working copy) for both the branch and the trunk, if for e.g. a bug pops up in the app I switch to the trunk and commit the change there, and then switch back to my branch for my project development.

My questions are:

  • Is this a sane way to work with branches?
  • Are there any pitfalls that I need to be aware of?
  • What would be the optimal way to work with branches if separate working copies are out of the question?

I haven't had issues yet as I have just started doing this way but all the tutorials/books/blog posts I have seen about branching with SVN imply working with different working copies (or perhaps I haven't come across an explanation of mixed working copies in plain English).

I just don't want to be sorry three months down the road when its time to integrate the branch back to the trunk.

share|improve this question
    
It's been my experience that branches in SVN just don't work good enough. Merging has always been a bit like playing Russian Roulette. Sometimes the merge goes well. Sometimes it blows away changes you didn't think would get blown away. Individually, you might be better off using Git-SVN. This gives you the branching and merging power of Git, but still makes The Beast happy because you are using SVN. –  Greg Burghardt Aug 25 at 13:40

4 Answers 4

up vote 8 down vote accepted

No

It's not a sane way to work with branches. If you have uncommitted changes on the branch, and then switch your working directory to the trunk, those changes will still be present. If those same files were patched on the trunk, then you will have merge conflicts. It won't be long before you will commit a change to the trunk that was intended for the branch.

Disk space costs about ten cents per Gigabyte. Checkout the trunk and branch separately.

I do occasionally use svn switch as follows:

  • checkout tagged release to reproduce problem
  • create patch branch
  • svn switch to patch branch. The workspace should not change.
  • commit fix
  • create new tag

I also build on production systems from SVN checkouts. There I use svn switch to update to a new release, rather than getting a fresh checkout. I never toggle a single workspace between two separate branches.

share|improve this answer

You can work this way quite happily - I do nowadays and is the way to work with feature branches. There are 2 pitfall you need to be aware of though.

  1. Any work you have uncommitted with remain in your working copy, and when you switch it will be merged. this can mean you may commit work intended for the other branch. Ultimately its a person problem - you need to be organised.

  2. Occasionally I will do work on a branch and realise, d'oh, I was using the wrong branch. Its easy to switch to the right one, keeping your work (as it gets merged when you switch). Still, you need to be organised.

I used ot checkout a new WC for each branch, which was a good workflow for the organisation we had in the previous company. With spare checkouts this is quick and easy. Now I use feature branches, all dev for any bug gets done on an individual branch and merged to trunk after various quality checks. This works well too except when you make a bugfix that doesn't get merged to trunk for some time (for "project" reasons typically). I can work on 4 or 5 branches a day with this workflow.

share|improve this answer

No, it is not sane.

First, your guys should really be working locally. If it is too hard to recreate an environment to run the app then you should address that.

Second, in scenarios where I was doing things in multiple long-running branches using SVN, the best / cleanest way to handle it I've found was to keep multiple working directories. Need to work on the trunk? Great, work in trunk folder. Need to work on the release branch? Great, just switch folders. Main issue was sometimes SVN would not like to switch and one would typically end up paving and re-checking out. This issue tended to crop up when one was often working in both branches. Was lots easier to just switch folders.

Then we went to hg and we don't have these problems . . .

share|improve this answer

This is not a pit fall - but a clear warning if you are starting out branches a fresh.

I just don't want to be sorry three months down the road when its time to integrate the branch back to the trunk.

When the work of the branch is complete - you want to merge, one needs to carefully not introduce diff in both ways which become incompatible. If it does happens - ideally you should take all changes from branch to trunk before going up.

Also, you must make sure you remember start of the SVN branch and last merge. If you take same revisions point and try to merge that diff twice - results will be problematic.

Branching is a must for all practically large projects.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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