CODEWITHSUNDEEP
svnversion-controlbranchbranching-and-merging
Andy
Andy

Reputation: 11462

How to structure SVN repo within the branches directory

I'm familiar with the classic /trunk /branches /tags structure for an SVN repo, but there seems to be very little advice on how to structure repo within that, especially the branches.

Let's say the top level of my source tree is a project called P. The trunk part of the repo is easy - it's just trunk/P because there's only one trunk.

For tags, I can structure them according to the version number so I would have 

tags/v3/v3.2/v3.2.7/P
tags/v3/v3.3/v3.3.1/P

etc. etc.

For branches, it's more complicated. I will typically have a "latest stable v3.2" branch but may also have active feature branches for 3.2. Of course I will also have feature branches for trunk, and it would seem to make sense to keep these separate from feature branches for other versions. So one option for repo structure would be:

branches/3.2/stable/P
branches/3.2/feature1/P
branches/trunk/feature2/P

It seems a bit odd to have a folder called trunk inside a branch though.

I guess a lot of people would say you should never do any feature development significant enough to require a branch unless that branch is directly from the trunk. In that case, the only branches would be feature branches and all tags would be from the trunk as well. Unfortunately I don't have that luxury because I have to support a number of old versions for customers who (for one reason or another) can't upgrade to the very latest.

Upvotes: 0

Views: 56

Answers (1)

Ben
Ben

Reputation: 8905

You structured your multi-project repository backwards from the recommended setup. You should put trunk, tags, and branches INSIDE project P rather than the other way around.

I think it makes very little sense to stick your tags into sub-tags like that. What are you hoping to gain by doing it that way? You wouldn't refer to a released version as 3/3.1/3.1.1. You would refer to it simply as 3.1.1. So why name your tags using the former method?

Branches make slightly more sense, and I can see where you're going with that, but I think I'd still recommend not making nested folders. I think you should develop a feature or bugfix in one branch (preferably off trunk, but that's not all that important) and then port it over to each other branch that needs it using a single merge revision. Then you just need a "feature1" and "feature2" branch instead of specifying where it comes from. The history should tell you where it comes from, and mergeinfo on each branch/trunk should tell you whether each branch has the feature or not.

Upvotes: 2

Related Questions