views:

38

answers:

3

I'm seeking opinions here. The following may be considered either an SVN-specific question, or a more general version control question.

If the sources of a project are to be branched at a point corresponding to a release, perhaps for maintenance work, is it preferable to:

(a) branch from the tag, or

(b) branch from the node (e.g. on the trunk) that the tag copies?

What are the pros and cons of these two approaches? Does it matter at all?

Thanks.

A: 

In partial answer to my own question:

(a) has the advantage of the branch being more obviously associated with a particular release or release candidate

(b) has the advantage of the trunk revision associated with the branch being more immediately obvious

Either way, it is possible to establish one from the other, although it is perhaps easier to get to the trunk from the tag rather than to find the tag from the trunk. Thus in this respect, (a) seems preferable.

In addition: when merging the branch maintenance back to the trunk, (b) seems to be the more natural option.

I would welcome any further opinions, thoughts or links.

Rhubbarb
+3  A: 

In my opinion, I would go the (a) route if I intend to add and patch the main project at a later date and go (b) If I intend to develop something parallel.

Dark Star1
+2  A: 

I'd suggest (b) since that will allow you to easily handing merging back to trunk using svn's merge tracking (assuming you have svn 1.5+ on the server and client side). If you used technique (a), you'd have to manage the merges yourself - which isn't bad assuming you don't do multiple merges from the same branch. Given that you are considering creating a branch from a tag, which usual for patching,, you'll probably end up needing to merge more than once to your trunk line to get those patches back in trunk.

Tags are a preferred way to take "snapshots" in time or to mark milestones of a particular code line (be it trunk or a branch) just for the purposes of quickly building a specific milestone from source that's been tagged as a milestone or for easily diff'ing between milestones. Other than that, all work is done between trunk and branches. As was already noted, you can easily find the revision/source a tag was copied from easily using svn log. For instance svn log --stop-on-copy -v tags/yourtag will put the latest copied revision at the tail of output. This allows you to create a branch from the revision an active code line from which the tag was created.

whaley
It turns out that you don't have to manage the merge yourself with (a); merge commands from branch to trunk work fine, using the mergeinfo. The only little 'problem' is that the mergeinfo on the trunk contains the tag URL with its creating revision in addition to the branch revision information. That is probably not what you want. On the other hand, it might not be considered a significant problem. [I have not experimented with reintegration; just an 'ordinary' merge.] To me, (b) feels like the right way to do things, but I'm still not strongly convinced that (a) is actually wrong as such.
Rhubbarb