Mercurial in a corporate environment (migration from CVS)

[Martin Geisler]

Stephen Morton <stephen.c.morton at gmail.com> writes:

Hi Stephen,

> At first, I really want people to adopt a CVS-like workflow until the
> whole team starts to understand how Mercurial works. Surprisingly to
> me, many really smart computer professional are not "hacker types" and
> never really play with their tools and never fully understand them.

Heh, I know what you mean :) We love version control on this list, but
most developers see it as a tool and have better things to do than to
worry about it.

> That's why, for instance, I want to ensure that the Apache
> authenticated username matches the changeset username: because it
> won't be a sign that somebody is doing something useful and clever, it
> will be a sign that somebody has a misconfigured .hgrc.

Okay, that's important to state. There are solutions involving
cryptographic signatures and whatnot and they can be used to really
enforce this policy. But they would be completely overkill when you're
not trying to protect against malicious users -- merely forgetful users.

> A thing I didn't mention before is that we're doing this now because
> we've got a great opportunity to experiment on a small team. So at
> first it will be just one branch, with no CVS history, and we can
> tweak the process/workflow as we go. But we still have to aim the
> whole thing at the larger group because that's where it would go
> eventually. (Either that or the whole project will be abandoned and
> all the Mercurial merged changes back into CVS.)

Sounds good -- always start with a small pilot project and work out the
kinks there.

> On Thu, Jan 12, 2012 at 9:32 AM, Martin Geisler <mg at aragost.com> wrote:
>
>> Stephen Morton <stephen.c.morton at gmail.com> writes:
>>
>> >    - Diffing. With cloned branches, will need the rdiff extension for
>> >    diffing *files* between releases.
>>
>> I don't think you need any special extension. The normal way is to
>> diff revisions inside the same repository. Remember that the
>> repository for version 2.0 will also contain the changeset for 1.0.
>> So
>>
>>  hg diff -r 1.0:2.0
>>
>> will work just fine.
>
> That will work just fine for all 1.0 content that was in the main repo
> before 1.0 cloned off the main trunk. All the subsequent bug fixes
> (and, ahem, the occasional late feature) in 1.0.1, 1.0.2 ... 1.0.15
> will not be in the 2.0 repository. We're supporting customers on old
> loads for years, and have years of bugfixes in every release branch.
> Hence the need for the rdiff extension.

Okay, I see why you need to diff 1.0.15 against 2.0. Then I'll suggest
using a named branch for the 1.x series. Call it 1.x and you'll be able
to run

  hg diff -r 1.x:2.0

The 1.x name will then always point to the latest (tip-most)
changesetset in the 1.x series.

You're of course also free to really use the rdiff extension, I'm just
trying to make sure you've seen the various options so that you can make
an informed choice :-)

>> Why use rebase instead of merging like "normal"? I'm a rebase fan
>> myself, but I feel obliged to tell you that it's an extension because
>> it offers users a bigger risk of messing things up than 'hg merge'
>> does.
>
> Yes, I'm worried about the risk. The benefit is a clean history. With
> this many designers working, there are going to be merges all the
> time. We have merges on a "cvs update" all the time with CVS and
> that's file-level merges, so repo-level merges with Hg are going to be
> very frequent. (>>10,000 files, 200 developers.) Seeing the history
> constantly having these mini-merges with two heads is just going to
> confuse people.

Good point. In any case, the conflicts that 'hg rebase' finds will be
very similar (often identical) to the ones that 'hg merge' finds. So
it's normall the same work to rebase as it is to merge.

>> [...] Now he suddenly have A--B--C--X--Y in one clone and a big ABC
>> changeset in the other. How to get X--Y moved over to ABC? It's not
>> difficult, but it requires more knowledge and more extensions.
>
> Again, at first we're working on a linear CVS-like workflow so we'd
> have a nice linear history. But agreed about the potential risk and
> grief.

It sounds to me like you've done a lot of homework -- more than most
people I've worked with. I think your Mercurial deployment will be a
great success!

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/