I have asked a question related to this on Stack Overflow, here: Mercurial: Class library that will exist for both .NET 3.5 and 4.0?.
I have a class library in Visual Studio 2008, written for .NET 3.5.
Now I wish to migrate this to Kiln, and in the process, set up both a .NET 4.0 version and a .NET 3.5 version. Both will be upgraded to Visual Studio 2010 however.
At the same time, I plan on rewriting some parts of the .NET 4.0 version, since the 3.5 version has a lot of old cruft that is basically obsoleted with the introduction of Linq. I did not remove it in 3.5 yet, since a few project I have in 3.5 use those features and I did not want to change those.
However, for new projects in 4.0, I can drop the old support and remove those things, simplifying a lot of code in the process.
So the two versions will diverge in some places. Yet, I also see bugfixes happening on code that is still common (or at the least pretty similar) in both.
How should I structure this?
From my SO question:
- Named branches in one repository, can then transplant any bugfixes from one to the other
- Unnamed branches in one repository, can also transplant, but I think this will look messy
- Separate repositories, will have to reimplement the bugfixes (or use a non-mercurial-integraded compare tool to help me)
Could there be a fourth option to use Kiln, by having branch repositories in the Kiln project? Should I make a base repository first, import the old VS2008 3.5 version there, then create sub-branch repositories for the 3.5 version and 4.0 version, and then upgrade both to VS2010 in those?
Or should I just create one for 3.5, upgrade it to VS2010, then create a sub-branch repository for 4.0, and adjust all the projects?
Or should I stay with one branch repository and use one of the 3 original ways I envisioned? I lean towards using named branches in that case.