Peter Memishian writes:
> I'm well aware of that model -- we started with it. I think it's a good
> model for larger (in terms of team members) project gates, but it's a poor
It also works great for project teams of one ... at least I can say
that it does for _me_.
> fit for us. Among other things, it makes everyday sync-ups more tedious
> (pull from two gates, merge, and push for usr/src, then have a separate
> procedure for usr/closed -- then repeat this across four layered repos).
I agree that usr/closed (as we also discussed on the phone) is a bit
of a crime scene. There needs to be a better answer for that.
However, for the most common users, you go from this (doing your work
right in the gate):
1. pull from Other Gate
2. merge
3. commit
4. test
5. fix up merge blunders
6. commit
to this (doing it properly in a child):
1. pull from parent
2. pull from Other Gate
3. merge
4. commit
5. test
6. fix up merge blunders
7. commit
8. push back to parent
In other words, two more steps, and simple ones at that. It doesn't
seem so bad to me, and it certainly hasn't proven unworkable in my own
practice gatekeeping in RBridges and Picea, and being a gateling of
SCM Migration.
I intend to do it the same way for all of the projects I work on.
> Really, I found it just plain awful for our workflow, and I wouldn't
> switch back to it without a compelling justification (e.g., external
> members on the I-team).
Would having a disaster recovery plan as part of your workflow be
helpful?
Suppose you merge in your gate, and something about the merge goes
horribly wrong -- you end up confused and unsure what bits you've got,
or you seek "help" from someone to merge an arcane area, and he just
makes it worse.
What will you do? If you do the merge in a child, it's simple: rm -rf
and start over. If you do it in the parent, you're toast.
> Anyway, getting back to my original question: what is the rationale
> behind Mercurial allowing pulls that would result in more than two
> heads by default? When would this be the behavior a developer would
> want by default?
Branches.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
