managing multi-version development with mercurial
Nicolas Dumazet
nicdumz at gmail.com
Tue Dec 1 20:31:10 CST 2009
Hello!
2009/12/2 Mike Jarmy <mjarmy at gmail.com>:
> Upon re-reading the above link, I think the
> guy who created the thread is having all sorts of problems with
> colleagues *pushing* bogus merges, which then get propagated all over
> before anyone sees that there is a problem. I am not aware of how you
> could fix that easily in git either. Thats why I'm interested in
> perhaps using hooks to somehow impose order; maybe its not really
> necessary in practice though.
>
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.
After all, hooks will only be covering bogus cases you thought of, and
if one of your colleagues does a mistake, it's likely that he will do
a mistake you did not warn him against -- aka you did not think about
in the first case.
What I am writing is simple: you have to think over your workflow,
instead of thinking over content/particular changesets. If you dont
want bogus changesets to check in, you have to set up a workflow that
allows reviewing incoming changes before propagation. In this view, a
central repo where everyone can push at will his/her changes seems
like a pretty bad perspective.
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.
You could, for example, pull yourself changes from other developer's
repo into the authoritative repo. This way, for the first days, you
can double-check what changesets are included in the repo.
Or you could give that authority to only a selected few.
Or you could set up one repo per team, with an individual responsible
for reviewing and including changes into the main repo.
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?
--
Nicolas Dumazet — NicDumZ
More information about the Mercurial
mailing list