2

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:

  1. Named branches in one repository, can then transplant any bugfixes from one to the other
  2. Unnamed branches in one repository, can also transplant, but I think this will look messy
  3. 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.

flag

1 Answer

2

There is no real distinction, in terms of how merging bug fixes will work, whether you choose to use named branches, anonymous branches, or separate repositories. In all cases, I'd suggest the following workflow:

  1. Upgrade your .NET 3.5 application to VS.NET 2010, since you plan to do that anyway
  2. Push this to Kiln
  3. Branch the repository in Kiln, either as a new central repository, or a branch.
  4. Begin developing the .NET 3.5 and .NET 4.0 versions separately
  5. When you get to a bug fix that's applicable to both, make it in the .NET 3.5 branch, then pull and merge the .NET 3.5 branch into the .NET 4.0 branch

This fifth step would read identically for named branches or anonymous heads.

link|flag
when in 3 you say "or a branch", do you mean branching inside the repository (ie. normal Mercurial branches, named or unnamed), or do you mean the branch feature on the popup-menu in the topright corner of the repository item in Kiln (ie. the one that reads "Branch - Create a copy of this repository in Kiln")? – Lasse V. Karlsen May 20 2010 at 14:58
I was suggesting that you use the branch feature from within Kiln that says "Branch - Create a copy of this repository in Kiln." I want to emphasize, though, that the above workflow works equally well if you opt to use Mercurial's named branches or lightweight Mercurial branches. The only thing that will change is that you'll be merging within the repository, rather than merging in another repository. Everything else--the workflow, the merge machinery invoked, etc.--is identical. – Benjamin Pollack♦ May 20 2010 at 15:05
Ok, thanks, I'll test this out then, seems promising :) – Lasse V. Karlsen May 20 2010 at 15:06
But... question. If I clone the 3.5 version into a 4.0 version, then perform all the changes in both that makes them diverge, then pull into 4.0 to get access to bugfixes I did in the 3.5 version, won't that make the 4.0 repository contain the entire 3.5 repository as well? Meaning, is there any point then in having two repositories at all? Seems like wasted diskspace and extra organization overhead to me... or? – Lasse V. Karlsen May 20 2010 at 15:11
The entire point is that your 4.0 repository should contain the entire history of the 3.5 codebase. What you don't want is for merging the 3.5 repository into the 4.0 repository to downgrade your 4.0 changes. Thankfully, it won't: that's the big difference between Subversion-style systems and Mercurial/Git-style systems. You'll only be merging in the changes done *since the fork*--which if you do as described above, will be since the 4.0 split. – Benjamin Pollack♦ May 20 2010 at 17:19
show 1 more comment

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.