Question

I’m new to source control in general and am wondering how to handle the following scenario:

Say I have an application written for one platform, say Windows Forms in .NET and I’ve developed it using Subversion (or any SCM software I suppose).

Now I’d like to update the application to use WPF and maybe add a few other enhancements. Would I continue the development in a branch from the tree for this WPF version 2.0?

There would maybe be some files that would remain the same that contain business logic, data access, etc. but really I would kind of want to start an entirely new solution and maybe borrow just a few things here and there from version 1.0.

What’s best practice? Create a new application folder with its own tree/branch/tag folders or try and keep the new version as part of the original 1.0 application folder?

How do you go about this?

Or in a less drastic case like upgrading an application from Silverlight 2 to Silverlight 3? What then?

I’d appreciate any guidance from those who have gone through this before.

Answer 1

There are generally a couple of schools of thought regarding version control, but the one I’ve encountered most often that makes sense to me is:

• You do all development that drives the project forward on the main branch, aka HEAD in CVS and ‘trunk’ in subversion. This one receives all the changes like the ones you describe, including changing GUI libraries, updating 3rd party tools and all that. The tip of that branch should always reflect the latest and hopefully greatest version of the software, but it will never see the light of day as a release.
• For every release, you create a release branch. All work related to the release and only to the release goes on this specific branch. These should mainly be bug fixes. Changes that you may make on this branch might get merged back into the main branch, but I wouldn’t expect many, if any changes from the main branch into the release branch. The main branch is a moving target whereas the release one isnt.