Strategies for push/merge problem?

Roman Kennke roman.kennke at
Mon Jul 14 14:07:44 CDT 2008

Hi Matt,

Thanks for your (and everybody else's) suggestions.

> On Mon, 2008-07-14 at 11:45 -0400, Doug Philips wrote:
> > On or about 2008-07-14 10:24:13, Roman Kennke inquired:
> > > As soon as there are more than 1 developers working on the code, you basically have to always do the push (fail) & pull & merge & commit & push (again) dance, which is a major pain.
> > 
> > Why not simplify it to:
> > % hg fetch
> > % hg push
> > 
> > Of course that is assuming a very CVS point of view that you don't need to bother to check/test the result of the fetch. Perhaps if the person doing this is getting emails from the central repo, they can know that things won't break...
> The only answer that actually scales is: don't use push.

Really, I 100% agree with you. The thing is, transitioning a team of
developers from CVS (or any other SCM for that matter) is only to a
small degree a technical problem. The bigger challenge is a social one.
When people are used for years to another SCM (and CVS is probably one
of the worse SCMs that is burned into brains) it is hard to beat that
way of thinking out of their brains again. Of course, I could try an
all-or-nothing approach, and not only install a new SCM and convert the
old repositories to the new one, but also install new processes
everywhere. But really, this wouldn't fly at all. People would probably
simply refuse to do anything with this, and get a very bad feeling for
HG, and probably won't touch it never again.

So my plan is to do it step by step. First, get them to use HG at all,
install the new repositories on a master server, as they are used to,
and setup a process, that is as close as reasonable possible to the old
processes. Let them start doing it, and 'feel' the advantages. At this
stage, it would be very helpful if HG is not 100% opposed to this
approach. I don't say it has to bend over backwards to allow a CVS-like
approach, but some extensions to make this easier surely would help.
It's even good if they feel _some_ pain, so I can then push them to use
the thing in a more HGish way. Which would be the next step(s). Change
the old behavious step by step into a good HGish development culture.
This is not something you want to do in one shot.

For now I think the keep-clean-in/out-repo will be the way to go for me.
And while people are doing this, I will try to lobby for a pull-only

I think it would be interesting to hear other people's experiences with
<OLD-SCM> -> HG transitions.

Dipl.-Inform. (FH) Roman Kennke, Software Engineer,
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt

More information about the Mercurial mailing list