On 10/19/06, Richard Lowe <[EMAIL PROTECTED]> wrote:
It is not just people who pull regularly, though they are more likely
to be victims, yes. It's anyone unlucky enough to have pulled that
change, and recovery is not entirely pleasant in the case you have
checked in local changes on top of the vanished delta.
As I understand the way things work now, the decision on whether to
undo is based on how many people have brought over that change. Which
it's currently not actually possible to check, via the hg mirror, and
will be racey either way.
Given that the divergence is one extra backout delta, and it saves any
risk of people having to manually prune a bad delta out their
workspaces (and there is no guarantee they won't have checked in over
it, since), it seems better to use the mechanism that least
inconvenience anyone involved.
Rich,
you are rising interesting points, but I think we should look at it from the
scope of ON gate leaving in TW and trying to migrate to hg and not
as at generic mercurial based project.
Correct me if I'm wrong, but ON today has a number of gates:
1. the gate where all the putbacks (hg push) are going.
This gate is the one where undo may happen. People generally discouraged
from bringing over (hg pull) directly from this gate.
2. the child of the gate above - it is being sync with its parent once
a day or so,
thus letting gatekeepers catch problems before they got a chance to spread out.
It is this gate that most of the people are bringing over (pulling) from.
What we have today available is a mirror from the first gate. With all
the pros and
cons. When switched to Mercurial I can imaging that two-gate scheme may be
preserved to facilitate the same behaviour.
Another point to consider is that today ON practice is to collapse all
the intermediate
deltas on individual project putback. Similar thing in Mercurial would be using
MQ extension. If used, it would keep the work of the individual
developer as a set of
patches anyway, so that stripping the bad changeset would hardly create any
serious inconvenience.
Does it sound reasonable or am I loosing something important here ?
--
Regards,
Cyril
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
