views:

88

answers:

3

I am part of a team that releases versions of our software 4-5 times each year to our customers. We maintain the previous 2-3 versions of our product by correcting any errors that we come across in later versions. We are using TFS 2008 for source control and are trying to find the best way of maintaining the older versions.

We currently create a branch of our application each time we do a new version, but we are looking for a good way to update old versions more easily. For example, we complete 9.5 but two weeks after we created the branch and are working on 10.0, we realize that 9.5 has an error. We currently make the change in version 10.0 and then open 9.5 to make the change again. Is there anyway of automating this?

Thanks!

+2  A: 

If you are creating a branch of your main source, then you should be able to make the correction to the bug in your main source and then "merge" that change to your 9.5 and 10.0 branches. That's part of the beauty of branching, namely, you can merge your changes from your main branch to the target branches.

When you choose the merge option with TFS, it will show you where the current source is branched, and you can choose which branches you want to merge those changes to. You shouldn't have to make the changes in your 9.5 and 10.0 branches manually, that really sort of defeats the purpose of branching in the first place.

dcp
I think that @AaronS has the better idea. Make the chnage in 9.5 and then merge through main to 10.0
MrHinsh
A: 

No, there is no way to "automate" this, and you dont really want to. What if the fix doesnt really need to be applied to each version?

It does sound to me like you are applying fixes backwards (first fix in older versions, then merge to newer).

StingyJack
+4  A: 

This is a main reason for branching and merging.

What I do in your situation is to make the change in 9.5 and then merge the change up into your main branch, and then back down into your 10.0 branch. The built in merge tool works well for this.

If you go the other direction you run the risk of adding new 10.0 stuff into your 9.5 branch when all you want is your bug fix.

I would also take a look at the TFS Branching Guides for more information on branching and merging.

AaronS
+1 for doing the bug fix in the oldest version that needs fixing. Much easier than merging from trunk to old versions.
sleske
wow... way to reiterate the 2nd paragraph in my post.
StingyJack
Hmmm; we always make the change in the trunk branch first and then merge specific changesets to earlier release branches. Do you never have merge headaches with your approach?
Kenny Evitt
@Kenny, that seems most natural to me too. One risks regressing behavior in later versions if you make the changes in "release" branches. I don't see how one direction or the other makes merging "easier". If there are unrelated changes on the trunk versions of files requiring forward- or reverse-integration, you'll pay the non-trivial merge penalty in either case.
David Gladfelter