Cyril Plisko wrote:
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.
I was thinking purely in terms of the mirroring machinery. ON going to
hg 'properly', I very much hope will include hooks preventing the kind
of changes that would be undone ever reaching the gate. (hooks checking
comment format, RTI, etc, etc, and refusing the push if they fail).
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.
With Teamware, yes. That would be onnv-gate.
2. the child of the gate above - it is being sync with its parent once
a day or so,
Yes, onnv-clone, which people bringover from, other than the last
bringover immediately before putback.
However, my understanding is that this split exists due to the way
teamware currently handles workspace locking. This isn't strictly
necessary with mercurial, but maybe nice.
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.
Yes, they bringover from the clone. However, not necessarily to avoid
such problems, but because Teamware's locking would otherwise tie the
gate up with bringovers for much of the time.
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.
I'm not sure it's strictly necessary to keep the clone in that case
(see above regarding hooks, and the TW locking bits), but it maybe nice
as a fixed-in-time merge point.
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.
Using Mq makes it less inconvenient, certainly, but doesn't remove all
inconvenience. It makes the "save your local changes off to the side,
and replace them afterward" part automatic, the rest is still manual.
Does it sound reasonable or am I loosing something important here ?
I think we're coming at this from different angles. As I said, my hope
is that for complete migration, the gate will refuse the kind of bogus
putback that would induce an undo, so at that point they will cease
entirely.
For now, I think that not inconveniencing people needlessly is the
better option. Especially when it's not currently possible for the
gate staff to know if anyone has pulled the change via mercurial.
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
