managing multi-version development with mercurial

[Mike Jarmy]

On Tue, Dec 1, 2009 at 9:31 PM, Nicolas Dumazet <nicdumz at gmail.com> wrote:
> I think that using hooks might not be enough to impose order,
> particularly if you want to avoid confusion in the first days after
> the conversion.

Its not so much bad changesets that worry me, as much as bad merges
between branches.  If someone merges the version5 branch onto
version4, and then pushes it, that would be very bad.  So I'll try to
experiment with a hook that detects merges between named branches, and
rejects them unless they conform to an allowed relationship between
the branches.

> In the end, you will probably need an authoritative repo which will
> contain the "master copy". But is it necessary to give everyone access
> to this repo? Maybe it's not. I think it's interesting to think about
> it.

Yes, I'm definitely thinking about what the workflow between
repositories will look like.  Our various teams and team members have
a lot of autonomy, which is good and its worked for us very well (we
have a great group of engineers).  We just need to figure out how to
map our defacto social organization onto hg, while making sure that
people don't *accidentally* break things that they did not intend to
break.  I think that moving to hg will, to an extent, change the way
we are organized.  The idea though is to make it better, not
disempower people who know what they are doing.

> Once a bogus changeset has been propagated, it's usually too late to
> fix the mess in a very clean way. The question you might need to ask
> yourself is: how can I limit the consequences of an human error?

Precisely.

-- Mike Jarmy