5

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.

Improve this question
1
  • 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, 2014 at 13:40

4 Answers 4

Reset to default
11

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.

Improve this answer
2

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.

Improve this answer
1

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

Improve this answer
1
  • +1 I was a sole developer for a project that often had a version in production, one in QA and one in development. Often there would be database schema changes between versions. This way of working kept me sane.
    – kiwiron
    Jun 11, 2022 at 19:51
0

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.

Improve this answer

Your Answer

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

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