views:

35

answers:

3

I have a LOB app that we use internally that is Winforms with a Linq to SQL DAL. I want to make a copy of this so that we can test some major changes going forward.

We use TFS 2010, is this what branching can do? I need to be able to edit GUI and DAL while being able to deploy it side by side with the Live version. Then, once the changes have been approved and tested properly merge it back in to the Live version and deploy it(we use ClickOnce currently).

How far can I take my branch, as in, can I rename the Assembly in the branch as well? Am I better of just creating a new version entirely if there are that significant of changes?

+1  A: 

Yes. Branching is the way to go. The merge process is pretty straightforward.

You should be able to rename a project, as long as you do it from the IDE.

jgauffin
+4  A: 

Yes, branching is the right way to go. You usually branch when you want to move away from the main "branch" of your software and develop something new on a different "branch" - like branches on a tree.

Branching might include a lot of thought of which branching strategy to use, so maybe this video with Brian Keller (Branching 101) can help you explain the different strategies, even though it is rather long with 42 Minutes.

Personally scenarios always help me, so you should most definitely check out the codeplex Project on TFS 2010 Branching stragies.

moontear
+1  A: 

Yes, go with branching. It creates a complete separate branch where you can do whatever you can in the original branch.

But if you have automated builds for the orignal branch those will not be available for your new branch.

Oddleif