|
Replies:
28
-
Last Post:
Oct 29, 2006 10:52 PM
by: dduvall
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
ON Mercurial repository mirror
Posted:
Oct 18, 2006 3:48 PM
|
|
It's up!
(well at least in read-only form for checkout - it'll be sometime still
before we have a full read-write repository)
First up: Please keep in mind this is part of the Mercurial beta
program... we will undoubtedly find errors and bugs along the way,
please have patience and bear with the occasional outage. I may have to
completely regenerate the repository thus stranding any children you
have. I apologise in advance(*1).
The repository can be checked out via:
$ hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
This will create an onnv-gate repository in your current directory.
The onnv-gate repository is a live MIRROR of the internal Teamware
onnv-gate workspace. It will be updated as putbacks happen real-time.
Please go to the onnv-notify mailman list(*2) and subscribe if you would
like to receive putback notifications as they happen.
Bonnie has put together a Mercurial help page (*3) which you can
reference if you need help on using Mercurial.
enjoy, and please send feedback to the tools-discuss list.
cheers,
steve
*1: backouts/ws_undos will quite possibly cause pain. only time (and
dduvall) will tell.
*2: http://mail.opensolaris.org/mailman/listinfo/onnv-notify/
*3: http://opensolaris.org/os/community/tools/scm/hg_help/
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
Posts:
1,253
From:
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 18, 2006 10:07 PM
in response to: stevel
|
|
So are we keeping track of who's pulling the gate, or at least when the
gate is pulled? One of the ways I decide whether to do a backout or an
undo is to look to see how many people have pulled the changes. If the
changes are severe enough to require an undo, then I notify the people who
pulled the undone change, and tell them how to handle it (unless it's just
the typical small set of people who bringover on every putback, and know
what to do). It'd be nice to be able to do the same thing for the external
mercurial gate.
Will undo notifications be sent to the notify alias, too?
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 18, 2006 10:44 PM
in response to: dduvall
|
|
On Wed, Oct 18, 2006 at 10:07:26PM -0700, Danek Duvall wrote:
> So are we keeping track of who's pulling the gate, or at least when the
> gate is pulled? One of the ways I decide whether to do a backout or an
> undo is to look to see how many people have pulled the changes. If the
> changes are severe enough to require an undo, then I notify the people who
> pulled the undone change, and tell them how to handle it (unless it's just
> the typical small set of people who bringover on every putback, and know
> what to do). It'd be nice to be able to do the same thing for the external
> mercurial gate.
>
> Will undo notifications be sent to the notify alias, too?
At the moment, we don't do any tracking of when or who is pulling clones
of the gate. I've currently got Teamware undo actions mapped to an 'hg
backout'. A direct 1:1 map would have mapped it probably to a 'hg
rollback && hg revert' - but I thought it would be easier (at least for
now) to map it to 'hg backout'.
While this isn't ideal in that it introduces a spurious changeset, it
makes it far easier to manage children that we don't want to "abandon"
in the case of an undo.
Since we map them to a 'backout', there will be a subsequent
notification corresponding to the backout sent to the notification
alias.
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Dean Roehrich
dean.roehrich@sun.com
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 7:56 AM
in response to: stevel
|
|
On Wed, Oct 18, 2006 at 03:48:37PM -0700, Stephen Lau wrote:
> *1: backouts/ws_undos will quite possibly cause pain. only time (and
> dduvall) will tell.
Unfortunately, I have no experience with TeamWare, and I don't quite
understand this problem.
If a changeset was deemed to be bad and needs to be removed then wouldn't you
just hg export that changeset and then re-apply it using 'patch -R' and commit
again with a note indicating what has happened?
Do TeamWare "backouts" remove the offending changeset and all changesets that
followed?
Dean
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 8:07 AM
in response to: Dean Roehrich
|
|
Dean Roehrich wrote:
> On Wed, Oct 18, 2006 at 03:48:37PM -0700, Stephen Lau wrote:
>
>> *1: backouts/ws_undos will quite possibly cause pain. only time (and
>> dduvall) will tell.
>
> Unfortunately, I have no experience with TeamWare, and I don't quite
> understand this problem.
>
> If a changeset was deemed to be bad and needs to be removed then wouldn't you
> just hg export that changeset and then re-apply it using 'patch -R' and commit
> again with a note indicating what has happened?
>
> Do TeamWare "backouts" remove the offending changeset and all changesets that
> followed?
The problem is Teamware "undo" operations remove the changeset entirely.
This breaks anyone who has updated/pulled/cloned the now-removed
changeset since their history doesn't line up with the canonical gate's
history.
I've worked around it by mapping "undo" => "hg backout" which applies a
reverse patch, but this means the history isn't 100% consistent with the
Teamware history now.
-steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 1:47 PM
in response to: stevel
|
|
On 10/19/06, Stephen Lau <stevel at sun dot com> wrote:
>
> The problem is Teamware "undo" operations remove the changeset entirely.
> This breaks anyone who has updated/pulled/cloned the now-removed
> changeset since their history doesn't line up with the canonical gate's
> history.
>
> I've worked around it by mapping "undo" => "hg backout" which applies a
> reverse patch, but this means the history isn't 100% consistent with the
> Teamware history now.
I think "hg strip" may do the job instead of "hg backout".
--
Regards,
Cyril
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/17/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 1:55 PM
in response to: imp
|
|
Cyril Plisko wrote:
> On 10/19/06, Stephen Lau <stevel at sun dot com> wrote:
>>
>> The problem is Teamware "undo" operations remove the changeset entirely.
>> This breaks anyone who has updated/pulled/cloned the now-removed
>> changeset since their history doesn't line up with the canonical gate's
>> history.
>>
>> I've worked around it by mapping "undo" => "hg backout" which applies a
>> reverse patch, but this means the history isn't 100% consistent with the
>> Teamware history now.
>
> I think "hg strip" may do the job instead of "hg backout".
>
No. In this case 'hg strip' would be identical to 'hg rollback && hg
revert'. (except strip needs a revision as an argument)
The problem with this, is that if someone has already brought over the
change you are about to vaporize, they need then need to do small
amounts of manual surgery to make their workspace remain valid:
At best, yes, 'hg strip' that delta, at worst:
1. export any local changes checked in on top of the bad delta.
2. strip the parent of the bad delta (such that both the bad delta, and
a second head caused by another 'pull' are removed).
3. hg pull -u, to bring yourself back to the real 'tip'
4. re-apply the changes from step 1
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 2:03 PM
in response to: richlowe
|
|
On 10/19/06, Richard Lowe <richlowe at richlowe dot net> wrote:
> Cyril Plisko wrote:
> > On 10/19/06, Stephen Lau <stevel at sun dot com> wrote:
> >>
> >> The problem is Teamware "undo" operations remove the changeset entirely.
> >> This breaks anyone who has updated/pulled/cloned the now-removed
> >> changeset since their history doesn't line up with the canonical gate's
> >> history.
> >>
> >> I've worked around it by mapping "undo" => "hg backout" which applies a
> >> reverse patch, but this means the history isn't 100% consistent with the
> >> Teamware history now.
> >
> > I think "hg strip" may do the job instead of "hg backout".
> >
>
> No. In this case 'hg strip' would be identical to 'hg rollback && hg
> revert'. (except strip needs a revision as an argument)
>
> The problem with this, is that if someone has already brought over the
> change you are about to vaporize, they need then need to do small
> amounts of manual surgery to make their workspace remain valid:
>
> At best, yes, 'hg strip' that delta, at worst:
>
> 1. export any local changes checked in on top of the bad delta.
> 2. strip the parent of the bad delta (such that both the bad delta, and
> a second head caused by another 'pull' are removed).
> 3. hg pull -u, to bring yourself back to the real 'tip'
> 4. re-apply the changes from step 1
Ok, so those bave souls who pull the upstream repo once a minute
and like to live on the bleading edge would have to do something,
but that os what happens today with TW anyhow (IIUC).
What exactly bothers you ?
--
Regards,
Cyril
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/17/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 2:11 PM
in response to: imp
|
|
Cyril Plisko wrote:
> On 10/19/06, Richard Lowe <richlowe at richlowe dot net> wrote:
>> Cyril Plisko wrote:
>> > On 10/19/06, Stephen Lau <stevel at sun dot com> wrote:
>> >>
>> >> The problem is Teamware "undo" operations remove the changeset
>> entirely.
>> >> This breaks anyone who has updated/pulled/cloned the now-removed
>> >> changeset since their history doesn't line up with the canonical
>> gate's
>> >> history.
>> >>
>> >> I've worked around it by mapping "undo" => "hg backout" which
>> applies a
>> >> reverse patch, but this means the history isn't 100% consistent
>> with the
>> >> Teamware history now.
>> >
>> > I think "hg strip" may do the job instead of "hg backout".
>> >
>>
>> No. In this case 'hg strip' would be identical to 'hg rollback && hg
>> revert'. (except strip needs a revision as an argument)
>>
>> The problem with this, is that if someone has already brought over the
>> change you are about to vaporize, they need then need to do small
>> amounts of manual surgery to make their workspace remain valid:
>>
>> At best, yes, 'hg strip' that delta, at worst:
>>
>> 1. export any local changes checked in on top of the bad delta.
>> 2. strip the parent of the bad delta (such that both the bad delta, and
>> a second head caused by another 'pull' are removed).
>> 3. hg pull -u, to bring yourself back to the real 'tip'
>> 4. re-apply the changes from step 1
>
> Ok, so those bave souls who pull the upstream repo once a minute
> and like to live on the bleading edge would have to do something,
> but that os what happens today with TW anyhow (IIUC).
>
> What exactly bothers you ?
>
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.
Beyond identicalness, what advantage does forceful pruning have?
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 2:33 PM
in response to: richlowe
|
|
On 10/19/06, Richard Lowe <richlowe at richlowe dot net> 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 at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/17/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 2:54 PM
in response to: imp
|
|
Cyril Plisko wrote:
> On 10/19/06, Richard Lowe <richlowe at richlowe dot net> 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 at opensolaris dot org
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 3:02 PM
in response to: richlowe
|
|
Richard Lowe wrote:
> Cyril Plisko wrote:
>> 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.
Yes, teamware uses reader/writer locking - you can have multiple readers or
a single writer at the same time, but that's it, so putbacks would have to
wait until no one was doing a bringover.
Teamware workspaces that aren't being shared by hundreds of developers don't
need do this, but can have a single gate used by both readers & writers.
(We don't have clone gates for X, CDE, etc.)
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 20, 2006 4:54 AM
in response to: richlowe
|
|
Richard Lowe wrote:
> 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.
undo/backout is not just done for "nit" like wrong commenting bad RTI
etc. It can also be done because the new code introduces a really bad
regression and is discovered before the build is closed. Some times the
developers are given a change to do a follow up integration to fix the
bug but in other cases there either isn't time or the bad code is so
toxic it needs to get out of the gate asap. One example of really toxic
code would be stuff that passes all the "nits" tests but just plain
fails to build or causes lots of build issues for others even if it does.
BTW here speaks the voice of experience, I did such a putback once when
updating openssl during Solaris 10 development. Yes I was very
embarrased because everything was working fine for me in my workspaces
but it causes issues in the main gate when it was integrated even though
it passed all the "nits" tests that wx putback runs.
--
Darren J Moffat
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/17/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 20, 2006 2:45 PM
in response to: darrenm
|
|
Darren J Moffat wrote:
> Richard Lowe wrote:
>> 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.
>
> undo/backout is not just done for "nit" like wrong commenting bad RTI
> etc.
Danek has said that ws_undo is only used for the nit-like issues, wrong
comments, branches, merge turds, etc.
Backouts being used for the other things you mention (and backouts
don't cause any of these problems, *only* forcefully removing a change
from ever having existed).
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 19, 2006 8:13 AM
in response to: Dean Roehrich
|
|
Dean Roehrich writes:
> Do TeamWare "backouts" remove the offending changeset
Yes.
> and all changesets that
> followed?
There aren't any.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
69
From:
Registered:
6/15/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 23, 2006 8:01 AM
in response to: stevel
|
|
Stephen Lau wrote:
> The onnv-gate repository is a live MIRROR of the internal Teamware
> onnv-gate workspace. It will be updated as putbacks happen real-time.
> Please go to the onnv-notify mailman list(*2) and subscribe if you
> would like to receive putback notifications as they happen.
Is it just me or is this definitely not the case? onnv-notify seems to
be out-of-sync with the actual putbacks, as I received a putback
notification yesterday (the 22nd) for "
6418698 PSARC/2005/334 - Packet Filtering Hooks API (fix cstyle)," but
according to the putback log, this was committed on the 21st. I'm also
getting onnv-notifications (ex. "6367849 kdb5_util will core dump if
krb5.conf doesn't contain default_realm info.") that haven't made it
into onnv-gate, yet.
There seem to be two issues here. (1) Is onnv-notify really real-time in
regards to putbacks? (whether or not onnv-gate is a mirror of the
internal Teamware repository or not is irrelevant here) (2) Is the
onnv-gate in sync (or really a real-time mirror) of the internal
Teamware repository?
--
Derek E. Lewis
delewis at acm dot org
http://riemann.solnetworks.net/~dlewis
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 23, 2006 8:12 AM
in response to: dlewis
|
|
Derek E. Lewis wrote:
> Stephen Lau wrote:
>> The onnv-gate repository is a live MIRROR of the internal Teamware
>> onnv-gate workspace. It will be updated as putbacks happen real-time.
>> Please go to the onnv-notify mailman list(*2) and subscribe if you
>> would like to receive putback notifications as they happen.
>
> Is it just me or is this definitely not the case? onnv-notify seems to
> be out-of-sync with the actual putbacks, as I received a putback
> notification yesterday (the 22nd) for "
> 6418698 PSARC/2005/334 - Packet Filtering Hooks API (fix cstyle)," but
> according to the putback log, this was committed on the 21st. I'm also
I see this notification:
http://mail.opensolaris.org/pipermail/onnv-notify/2006-October/002947.html
that went out on Sat Oct 21 @ 23:16:37 PDT
Going into the onnv-gate repository, I see:
changeset: 3001:a0fedf4579de
user: dr146992
date: Sat Oct 21 23:16:22 2006 -0700
summary: 6418698 PSARC/2005/334 - Packet Filtering Hooks API (fix
cstyle)
Is it possible you're getting a mail delay?
> getting onnv-notifications (ex. "6367849 kdb5_util will core dump if
> krb5.conf doesn't contain default_realm info.") that haven't made it
> into onnv-gate, yet.
changeset: 3005:41bbfbd457d9
user: mp153739
date: Mon Oct 23 06:15:58 2006 -0700
summary: 6367849 kdb5_util will core dump if krb5.conf doesn't
contain default_realm info.
> There seem to be two issues here. (1) Is onnv-notify really real-time in
> regards to putbacks? (whether or not onnv-gate is a mirror of the
> internal Teamware repository or not is irrelevant here) (2) Is the
> onnv-gate in sync (or really a real-time mirror) of the internal
> Teamware repository?
Yes and yes.
When someone internally commits to the internal Teamware onnv-gate
repository, it gets bridged to my internal Hg onnv-gate within a few
seconds. Immediately after the bridge is complete (usually less than 30
seconds, depending on how many SCCS gets the bridge has to execute), it
gets pushed to the external repository. So the external gate shouldn't
lag by more than a minute or so.
Once the external gate receives the `hg push` and completes, it fires
off an email to mailman - so the mailman processing occurs real-time
with regard to the putback completion.
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
69
From:
Registered:
6/15/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 23, 2006 10:01 AM
in response to: stevel
|
|
Stephen Lau wrote:
> Is it possible you're getting a mail delay?
Very possible -- I should've checked the onnv-notify archive before
sending off griping. :-)
>
> When someone internally commits to the internal Teamware onnv-gate
> repository, it gets bridged to my internal Hg onnv-gate within a few
> seconds. Immediately after the bridge is complete (usually less than
> 30 seconds, depending on how many SCCS gets the bridge has to
> execute), it gets pushed to the external repository. So the external
> gate shouldn't lag by more than a minute or so.
>
> Once the external gate receives the `hg push` and completes, it fires
> off an email to mailman - so the mailman processing occurs real-time
> with regard to the putback completion.
I believe I figured out where my confusion is coming from (being a
CVS/Subversion user). 'hg pull' seems to be equivalent to 'svn up' or
'cvs up' rather than 'hg update,' which is why I wasn't seeing the
updated files for each putback.
Thanks!
--
Derek E. Lewis
delewis at acm dot org
http://riemann.solnetworks.net/~dlewis
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 23, 2006 10:07 AM
in response to: dlewis
|
|
Derek E. Lewis wrote:
> Stephen Lau wrote:
>> Is it possible you're getting a mail delay?
>
> Very possible -- I should've checked the onnv-notify archive before
> sending off griping. :-)
>
>>
>> When someone internally commits to the internal Teamware onnv-gate
>> repository, it gets bridged to my internal Hg onnv-gate within a few
>> seconds. Immediately after the bridge is complete (usually less than
>> 30 seconds, depending on how many SCCS gets the bridge has to
>> execute), it gets pushed to the external repository. So the external
>> gate shouldn't lag by more than a minute or so.
>>
>> Once the external gate receives the `hg push` and completes, it fires
>> off an email to mailman - so the mailman processing occurs real-time
>> with regard to the putback completion.
>
> I believe I figured out where my confusion is coming from (being a
> CVS/Subversion user). 'hg pull' seems to be equivalent to 'svn up' or
> 'cvs up' rather than 'hg update,' which is why I wasn't seeing the
> updated files for each putback.
Try doing 'hg pull -u' which will both pull the new changes, as well as
update your working copy.
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Thomas Arendsen...
thomas@intevation.de
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 23, 2006 1:55 PM
in response to: dlewis
|
|
* Derek E. Lewis <dlewis at solnetworks dot net> [20061023 19:01]:
> I believe I figured out where my confusion is coming from (being a
> CVS/Subversion user). 'hg pull' seems to be equivalent to 'svn up'
> or 'cvs up' rather than 'hg update,' which is why I wasn't seeing
> the updated files for each putback.
With 'hg pull' you transfer the data to your local repository, which
lives in the .hg subdirectory of your working copy. After this you
can use the cvs-like 'hg update' or use one of its aliases.
Personally I use the alias 'hg co' (or checkout) to unconfuse
myself, though the official name is update.
Regards,
Thomas Arendsen Hein
--
Email: thomas at intevation dot de
http://intevation.de/~thomas/
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,253
From:
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 28, 2006 6:02 PM
in response to: stevel
|
|
|
|
On Mon, Oct 23, 2006 at 08:12:11AM -0700, Stephen Lau wrote:
> Is it possible you're getting a mail delay?
I am, at least. It's quite variable. Most of the time, the messages come
in within five to ten minutes after putback (which is still quite bad).
But, for instance, Bill's putback yesterday didn't register on onnv-notify
until this afternoon -- 22 hours and 30 minutes after the putback happened
internally. I've attached my copy of Bill's message for reference.
I'm not sure where the problem was there. The mail appears to have been
sent only(!) twelve minutes before it arrived, with the bulk of that delay
being between the last mailserver in the opensolaris.org domain and the
first in the sun.com domain (so maybe others didn't have that particular
delay). This would point to it taking a long time for the mirror to have
happened.
I'll note that the notification for Darren's putback this afternoon to a
minute and ten seconds to make it to me once it was sent, so the twelve
minutes for Bill's putback wasn't just clock skew. (The time for the
mirror to run, assuming that there's no skew, was about another minute and
ten seconds.)
As gatekeeper I've generally tried to stay very on top of putbacks as they
come through, often checking who's on the gate machine and what they're
doing. I probably won't need to be nearly so proactive once we have
stronger pre-putback checking, but I still feel that timely notifications
are going to be very important, and preserving ordering will be pretty
critical, too, when it comes to incremental builds.
Perhaps I just have to relax a bit? :)
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/17/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 29, 2006 12:25 PM
in response to: dduvall
|
|
Danek Duvall wrote:
> On Mon, Oct 23, 2006 at 08:12:11AM -0700, Stephen Lau wrote:
>
>> Is it possible you're getting a mail delay?
>
> I am, at least. It's quite variable. Most of the time, the messages come
> in within five to ten minutes after putback (which is still quite bad).
> But, for instance, Bill's putback yesterday didn't register on onnv-notify
> until this afternoon -- 22 hours and 30 minutes after the putback happened
> internally. I've attached my copy of Bill's message for reference.
>
> I'm not sure where the problem was there. The mail appears to have been
> sent only(!) twelve minutes before it arrived, with the bulk of that delay
> being between the last mailserver in the opensolaris.org domain and the
> first in the sun.com domain (so maybe others didn't have that particular
> delay). This would point to it taking a long time for the mirror to have
> happened.
Notifications are, as I understand it, sent from the opensolaris.org
side. So the internal mirror may happen quickly, but drag in being
pushed to the onnv-gate on opensolaris.org, or in sending out the
notification after that.
It'd be interesting to see which it is (I'd say a mail problem was less
important than the actual gate dropping back..., but maybe others would
disagree).
> I'll note that the notification for Darren's putback this afternoon to a
> minute and ten seconds to make it to me once it was sent, so the twelve
> minutes for Bill's putback wasn't just clock skew. (The time for the
> mirror to run, assuming that there's no skew, was about another minute and
> ten seconds.)
>
> As gatekeeper I've generally tried to stay very on top of putbacks as they
> come through, often checking who's on the gate machine and what they're
> doing. I probably won't need to be nearly so proactive once we have
> stronger pre-putback checking, but I still feel that timely notifications
> are going to be very important, and preserving ordering will be pretty
> critical, too, when it comes to incremental builds.
>
> Perhaps I just have to relax a bit? :)
>
No, you shouldn't. I'd say anything with the slightest chance of
indicating a problem in either the bridging machinery, or the SCM
implementation on opensolaris.org should be brought up. The more
problems found now, the less you'll run into later :)
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Thomas Arendsen...
thomas@intevation.de
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 29, 2006 1:50 PM
in response to: dduvall
|
|
* Danek Duvall <danek dot duvall at sun dot com> [20061029 02:02]:
> On Mon, Oct 23, 2006 at 08:12:11AM -0700, Stephen Lau wrote:
> > Is it possible you're getting a mail delay?
>
> I am, at least. It's quite variable. Most of the time, the messages come
> in within five to ten minutes after putback (which is still quite bad).
> But, for instance, Bill's putback yesterday didn't register on onnv-notify
> until this afternoon -- 22 hours and 30 minutes after the putback happened
> internally. I've attached my copy of Bill's message for reference.
> From: William dot Kucharski at sun dot com
I suggest always sending the notifications with the same From
header, otherwise Mailman moderation, greylisting, checking of
sender domain and such things may contribute to the problems you
experience.
Regards,
Thomas
--
Email: thomas at intevation dot de
http://intevation.de/~thomas/
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 29, 2006 10:09 PM
in response to: dduvall
|
|
Part of the problem is we seem to randomly experience either an
autofs-timeout problem, either related to NFS or to the SCM automount
map not being ale to access the database quickly enough.
This sometimes causes SCM operations to fail the first time but work a
subsequent repeated time. Unfortunately, I've seen a couple of times
now where upon putback - the bridge tries to do a 'hg push', and fails -
and doesn't try again (I'll try to modify it to do a retry tomorrow).
So the actual 'hg commit' happens - but the push doesn't.
What usually happens instead is that upon the next push, it will be
pushed then (assuming that one works).
This is definitely a problem in our SCM environment and we're looking
into it..
Hope that explanation made sense...
cheers,
steve
On Sat, Oct 28, 2006 at 06:02:37PM -0700, Danek Duvall wrote:
> On Mon, Oct 23, 2006 at 08:12:11AM -0700, Stephen Lau wrote:
>
> > Is it possible you're getting a mail delay?
>
> I am, at least. It's quite variable. Most of the time, the messages come
> in within five to ten minutes after putback (which is still quite bad).
> But, for instance, Bill's putback yesterday didn't register on onnv-notify
> until this afternoon -- 22 hours and 30 minutes after the putback happened
> internally. I've attached my copy of Bill's message for reference.
>
> I'm not sure where the problem was there. The mail appears to have been
> sent only(!) twelve minutes before it arrived, with the bulk of that delay
> being between the last mailserver in the opensolaris.org domain and the
> first in the sun.com domain (so maybe others didn't have that particular
> delay). This would point to it taking a long time for the mirror to have
> happened.
>
> I'll note that the notification for Darren's putback this afternoon to a
> minute and ten seconds to make it to me once it was sent, so the twelve
> minutes for Bill's putback wasn't just clock skew. (The time for the
> mirror to run, assuming that there's no skew, was about another minute and
> ten seconds.)
>
> As gatekeeper I've generally tried to stay very on top of putbacks as they
> come through, often checking who's on the gate machine and what they're
> doing. I probably won't need to be nearly so proactive once we have
> stronger pre-putback checking, but I still feel that timely notifications
> are going to be very important, and preserving ordering will be pretty
> critical, too, when it comes to incremental builds.
>
> Perhaps I just have to relax a bit? :)
>
> Danek
> Date: Sat, 28 Oct 2006 16:33:55 -0700 (PDT)
> From: William dot Kucharski at sun dot com
> Subject: 6485375 in same process group,
> parent set child as process group lead should succeed
> To: onnv-notify at opensolaris dot org
>
> Author: kucharsk
> Repository: /hg/onnv/onnv-gate
> Revision: 059923cf64160e6cbcf39a150fcf682d762e1cfa
> Log message:
> 6485375 in same process group, parent set child as process group lead should succeed
> 6485379 setpgid should follow man page to set errno
>
> Files:
> update: usr/src/lib/brand/lx/lx_brand/common/pgrp.c
> _______________________________________________
> onnv-notify mailing list
> onnv-notify at opensolaris dot org
> http://opensolaris.org/mailman/listinfo/onnv-notify
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,253
From:
Registered:
3/9/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 29, 2006 10:52 PM
in response to: stevel
|
|
On Sun, Oct 29, 2006 at 10:09:15PM -0800, Stephen Lau wrote:
> Hope that explanation made sense...
Yep. It's sad, but it certainly explains the grouping.
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,323
From:
DE
Registered:
6/16/05
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 25, 2006 3:53 AM
in response to: stevel
To: Communities » tools » discuss
|
|
> It's up!
> (well at least in read-only form for checkout - it'll be sometime still
> before we have a full read-write repository)
...
> The repository can be checked out via:
> $ hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
Hmm, doesn't work for me. I get a "permission denied" error from the server:
% hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
remote: Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
abort: no response from remote hg!
Is that a temporary server failure? Or am I missing some additional
setup steps, for an anoymous repository checkout ?
|
|
|
|
|
Posts:
303
From:
IE
Registered:
1/19/06
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 25, 2006 4:03 AM
in response to: jkeil
|
|
Jürgen,
There is a temporary problem accessing the servers
at the moment, which *may* be the cause of your
problem.
Please try again later today.
- Dermot
Jürgen Keil wrote:
>> It's up!
>> (well at least in read-only form for checkout - it'll be sometime still
>> before we have a full read-write repository)
> ...
>> The repository can be checked out via:
>> $ hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
>
> Hmm, doesn't work for me. I get a "permission denied" error from the server:
>
> % hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
> remote: Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
> abort: no response from remote hg!
>
>
> Is that a temporary server failure? Or am I missing some additional
> setup steps, for an anoymous repository checkout ?
>
>
> This message posted from opensolaris.org
> _______________________________________________
> tools-discuss mailing list
> tools-discuss at opensolaris dot org
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Thomas Arendsen...
thomas@intevation.de
|
|
|
|
Re: ON Mercurial repository mirror
Posted:
Oct 25, 2006 6:27 AM
in response to: dermot
|
|
* Dermot McCluskey <Dermot dot McCluskey at Sun dot COM> [20061025 13:03]:
> Jürgen Keil wrote:
> >Hmm, doesn't work for me. I get a "permission denied" error from the server:
> >% hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
> >remote: Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
> >abort: no response from remote hg!
>
> There is a temporary problem accessing the servers
> at the moment, which *may* be the cause of your
> problem.
The repository is accessible again, but during the downtime I didn't
get "Permission denied" errors.
In case there are problems in the future (or if you just want to
look at the web interface), you can use the (unofficial and hourly
updated) mirror I've set up last week:
http://hg.intevation.org/mirrors/opensolaris.org/onnv-gate/
Regards,
Thomas Arendsen Hein
--
Email: thomas at intevation dot de
http://intevation.de/~thomas/
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,323
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: ON Mercurial repository mirror
Posted:
Oct 25, 2006 9:36 AM
in response to: dermot
To: Communities » tools » discuss
|
|
Yep, a few hours later, the same "hg clone " command worked,
without giving me "permission denied" errors any more.
> There is a temporary problem accessing the servers
> at the moment, which *may* be the cause of your
> problem.
>
> Please try again later today.
> Jürgen Keil wrote:
> >> It's up!
> >> (well at least in read-only form for checkout - it'll be sometime still
> >> before we have a full read-write repository)
> > ...
> >> The repository can be checked out via:
> >> $ hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
> >
> > Hmm, doesn't work for me. I get a "permission denied" error from the server:
> >
> > % hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate
> > remote: Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
> > abort: no response from remote hg!
> >
> >
> > Is that a temporary server failure? Or am I missing some additional
> > setup steps, for an anoymous repository checkout ?
|
|
|
|
|
