How to handle new versions of a .NET application in Subversion?

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

You tag what's currently in the head of the repository as being "version 1.0"/etc.

Answer 2

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.

Answer 3

I structure my projects this way:

/branches (different working sets)
/tags     (revisions, etc)
/trunk    (current production state)
  /lib      (3rd party libraries and dependencies)
  /tools    (build tools)
  /src
    /component-a
    /component-b
    /component-c

Because subversion only tracks deltas for each commit, there isn't a server-side penalty to branching everything under trunk. The only consideration is how much disk space on your local machine you want to use.

When you roll out code, "tag" it under the tags. When you need to spin off experimental code, create a branch.

EDIT: In terms of challenges associated to sharing a libraries between different OS or runtime environments, it really depends on how large the project and components are. In some cases, it makes sense to split out "core" logic into its own project, and export a "versioned" compiled library to your (potentially) many consumers. This approach only works well if the core logic is stable and doesn't version often.

Answer 4

From your comment on @Timo Geusch it seems your question is about something else than handling versions of released software, which is more about picking an arbitrary number. Rearranging your code has little to do with version control and more about how you've set up your .NET solution (i.e. code architecture). Lets take the following example, rather badly named:

MySolution
    /MyWinFormsProject

In this example we have a solution called MySolution. It one project, that is a WinForms one called MyWinFormsProject. When we want to switch from having a WinForms project to a WPF one it'll be problematic because most of the code you had in that Winforms application will need to be rewritten. And if you have 10000+ lines of code, this will be a harrowing task.

If you're in this situation you really should start refactor by ripping out the common code and place that in another project (preferably a Class Library one) which we could call MyCommonCode. Remember that you need to reference MyCommonCode in MyWinFormsProject.

MySolution
    /MyWinFormsProject
    /MyCommonCode

Commit when you're done, revision number will bump up. You can revert back to this in case you've screwed up later. Next create the new project, a WPF one called MyWPFProject. You only need to set the MyWPFProject as start-up project if you want to start from that one instead.

MySolution
    /MyWinFormsProject
    /MyCommonCode
    /MyWPFProject

When you've done that, commit again. No need to remove the WinForms project until you're done with WPF one.

Note: How to exactly divide and name your projects and namespaces is up to you, though looking at some open souce projects will help give you inspiration.