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.

Answer 2

Branching keeps your history together and allows you to see the complete genesis of your project. Also it might be possible (depending on product and state of disarray) to merge fixes from a released version into the "next" version, which may or may not reduce work to keep this in sync.

Answer 3

I am not a TFS specialist, but I do have a "strong" opinion about branches and tags.

A branch, in any VCS, should be reserved to isolate a development effort not compatible with the current one.

That means that, whatever the environment (branch or no branch) in which you are currently working, if you can not go on with your current development while initiating those drastic refactoring you mention, then you need a branch.
In that branch, the history of your files can take a new path while still being recorded

The trick is to not to interpret a tag for a branch, especially if both are represented as directory.

V2.0 could be interpreted both as a:

• tag where the history of the files should be fixed and immutable
• branch where the history evolves up until the 2.0 release

I would recommend a naming convention that clarify the intent behind the directory:
V2.0_Refactoring for instance would be clearer and indicate a branch.

Answer 4

The branching strategy that's worked best in my experience is having a single "mainline" trunk, branches for each major version off of that, and then branches for smaller releases off each of those as required. Most work gets done in mainline, and then as we get pretty close to a release we branch off and stabilize the branch.

You can branch for arbitrarily small change sets/releases, but there eventually gets to too much cognitive overhead to make them worthwhile. You can also create more temporary branches to isolate big works-in-progress from the main branches until the changes are ready to be merged in.

With all that as context, I don't see much value in "starting fresh" at the beginning of a release. Even if, by the end of the release, everything is going to be changed, you still want a complete history of how things have evolved over time. I'm presuming TFS keeps track of moves/renames/deletions, etc. so even if you're doing lots of file-level changes, that's valuable history to have.

Answer 5

You may want to have a look at some articles on best practices:

• High-level Best Practices in Software Configuration Management
• Advanced SCM Branching Strategies
• Merging is the key to software developer collaboration

In your case, I would not create a branch to host your V-next. You should only create that branch when you are ready to deliver to your customer by creating a packaging branch.

I would create some short term branches (1 for each scrum iteration) to host your risky developments and merged them back at the end of each iteration. Only create development branches for risky developments such as the intense refactoring you are talking about.

Your main branch should always be stable. Ready to deliver to customers or at least ready to branch out for a packaging branch.

I also recommend SCM Patterns.

Answer 6

Read this: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf