tags:

views:

96

answers:

4

How do you maintain two (or more) versions of a project in SVN? different trunks, inside the main trunk? branches? Totally separate folders?

I currently have, assuming I am about to make v2 of ProjecA, but I still need to fix bugs in v1:

\ProjectA\trunk\[myfiles]
\ProjectA\tags\
\ProjectA\branches\

Which would be the best way to do that?

\ProjectA\trunk\[myfiles]
\ProjectA\tags\
\ProjectA\branches\v1\[myfiles]
\ProjectA\branches\v2\[myfiles]

OR would something like this be better?

\ProjectAv1\trunk\[myfiles]
\ProjectAv1\tags\
\ProjectAv1\branches\

\ProjectAv2\trunk\[myfiles]
\ProjectAv2\tags\
\ProjectAv2\branches\

Which would you use, and more specifically, why? I am leaning toward the first option, but something about it feels wrong. At the same time, the second option seems clean, but ugly.

Any thoughts are appreciated.

+7  A: 

The usual approach is pretty much exactly your middle example. There's a good discussion of branching patterns in the subversion documentation.

rmeador
Lots of other great stuff on subversion at that link as well. Thanks!
Nate Bross
The documentation does *not* recommend his middle example. He should not create a new branch for v2 until he begins working on v3.
gWiz
Correct, the versioned branches (v1, v2, v3) are only for once those versions are in maintenance mode.
Nate Bross
+1  A: 

I think this was covered very well here: manage-merging-updates-from-several-developers

The short version,

/Project/trunk
/project/tags/version1
/project/branches/version1-sp1 <- when sp1 ships, create 
/project/tags/version1-sp1  <- and a branch off this called 
/project/branches/version1-sp2

/Project/trunk will always contain your HEAD/MASTER code, and any version specific modifications go into a separate branch.

When the time comes to start on version 3, you create another tag/branch combo.

/Project/tags/version2 <- for the shipped version 
/Project/branches/version2-sp1 <- for fixes/features.
Chris Kaminski
A: 

Remember that "trunk" is just another branch -- the only meaning given to these directory names is what you give it. So if your application has separate versions v1, v2, v3.. that have totally different directions of development, you could put a trunk inside each version like so:

\ProjectA\v1\trunk\[myfiles]
\ProjectA\v1\tags\
\ProjectA\v1\branches\[myfiles]
\ProjectA\v2\trunk\[myfiles]
\ProjectA\v2\tags\
\ProjectA\v2\branches\[myfiles]

Or (and I think I prefer this better), a variant of your option #2 where you keep the normal trunk/tags/branches structure at the high level, but just abandon the idea of a global trunk (because really there's a trunk for each version):

\ProjectA\trunk\v1\[myfiles]
\ProjectA\trunk\v2\[myfiles]
\ProjectA\tags\
\ProjectA\branches\v1\[myfiles]
\ProjectA\branches\v2\[myfiles]
Ether
+1  A: 

I think its best to do

\ProjectA\trunk\[myfiles] <= this becomes v2
\ProjectA\tags\
\ProjectA\branches\v1\[myfiles]

I believe this best retains the meaning of trunk.

gWiz