How to handle branching when you're planning on doing a rewrite in the future?

Question

My development team is moving to branching soon - we've been cursed with SourceSafe and we're moving to Team Foundation Server - and I'm curious about something.

Traditionally when we do major revisions to our product, to the point where not even the folder structure or the filenames stay the same, we do a new root folder in source control.

For example

$/V1.0
$/V1.1
$/V1.5
$/V2.0

and so forth.

I'm brand new to branching and one of the things I'm reading is that you can use different branches for the various versions of your product. Now, when you're talking about doing a hotfix or a small change or modification to the code - where at worst you might be adding new files - this makes sense.

However when doing a "V-Next" version of your product, where you are planning on doing a more or less complete rewrite of the product (not from scratch, but rather reworking it drastically), to the point where the folder structure and file names will likely be completely different, is that still something you would want to do through branching? Or would you want to create a new root ($/V2.0 above) to handle it?

Answer 1

Our development team uses a pretty standard branching structure in Subversion. In the main repository we have 3 folders:

• branches
• tags
• trunk

In your example, all of the V* folders would go under tags. All of the main development happens in trunk, and we use branches when we need to have a variation on what is in trunk for another project.

We also use branches to store drastic changes to trunk. This is good practice in case you need to fix a bug in trunk before your rewrites are complete. So, we'd create a "V-Next" branch under branches, and when it is complete, we would merge that branch back into trunk.