Mike Kupfer writes:
>> "Rich" == Richard Lowe writes:
>
>>> But with Mercurial it could also be implemented as a tag in a single
>>> gate workspace.
>
> Rich> No, it couldn't, tags introduce changesets.
>
> Okay, but why is that a problem? Instead of , we
> have plus one changeset to set t
Mike Kupfer writes:
>> "Ken" == Ken Erickson writes:
>
> Ken> I'm not sure throwing away the collective wisdom of 20 years worth
> Ken> of gatekeepers is such a good idea.
>
> I agree, but I think we should try to separate out the "wisdom" parts
> from the artifacts of the implementation.
W
http://bugs.grommit.com/show_bug.cgi?id=356
--- Comment #2 from richlowe at richlowe.net 2007-10-04 22:29 PDT ---
(In reply to comment #1)
> Should we punt in the case we would be removing the node referenced by a
> non-local tag
>
To mean erroring, and asking the user to hg tag --r
http://bugs.grommit.com/show_bug.cgi?id=356
--- Comment #1 from richlowe at richlowe.net 2007-10-04 22:28 PDT ---
For local tags this is trivial (and becomes more trivial with a newer
mercurial).
For 'real' tags this becomes more complex, as the removal of the tag would
introduce a ch
Richard Lowe wrote:
> Mike Kupfer writes:
>
>
>>> "Rich" == Richard Lowe writes:
>>>
But with Mercurial it could also be implemented as a tag in a single
gate workspace.
>> Rich> No, it couldn't, tags introduce changesets.
>>
>> Okay, but why is t
> "Rich" == Richard Lowe writes:
>> But with Mercurial it could also be implemented as a tag in a single
>> gate workspace.
Rich> No, it couldn't, tags introduce changesets.
Okay, but why is that a problem? Instead of , we
have plus one changeset to set the tag. What am I
missing?
mike
> "Ken" == Ken Erickson writes:
Ken> I guess what I am wondering is, are we planning to use hooks to
Ken> closely mimic the current behavior of teamware, or is someone
Ken> re-inventing something else? Or is this part of what I should be
Ken> doing as I work on these gate scripts?
I think t
> "Ken" == Ken Erickson writes:
Ken> I'm not sure throwing away the collective wisdom of 20 years worth
Ken> of gatekeepers is such a good idea.
I agree, but I think we should try to separate out the "wisdom" parts
from the artifacts of the implementation.
For example, I (and others) want t
> "Rich" == Richard Lowe writes:
>> FYI, I'm planning to list all the ON developer tools on a similar
>> table and show owners and status information.
Rich> I think we had that somewhere... SCMMigrationTasks perhaps?
That was the original planning list. At this point, if we keep it at
all,
.org/pipermail/scm-migration-dev/attachments/20071004/4e3bd822/attachment.bin>
>> Anyway, how will commit notifications be handled using hg? Has there
>> been a policy decision about this? Will a hook be used to email
>> the changes to a list? If so, then buglist really doesn't have
>> to change much.
>
>Yes, they'd continue going to onnv-notify, at least in part.
>buglis
Richard Lowe wrote:
> Bonnie Corwin writes:
>
>
>> Hi,
>>
>> I'm trying to update the SCM Migration Project task list on genunix.org.
>>
>> There is a pointer to a list of gatekeeper tools:
>> http://www.genunix.org/wiki/index.php/gateTools
>>
>> There are two columns on this table that have d
Bonnie Corwin writes:
> Hi,
>
> I'm trying to update the SCM Migration Project task list on genunix.org.
>
> There is a pointer to a list of gatekeeper tools:
> http://www.genunix.org/wiki/index.php/gateTools
>
> There are two columns on this table that have data in them: Port and Done.
>
> Doe
#353 'hg list' output should be sorted properly, into an actual order
http://bugs.grommit.com/show_bug.cgi?id=353
cr.opensolaris.org/~richlowe/scm_353
When I made hg list sort, I foolishly and negligently missed sorting
the actual groups, as well as the files within the group.
You'll note the
http://bugs.grommit.com/show_bug.cgi?id=356
Summary: cdm recommit needs to cope with the tags it may be
trashing
Product: SCM Migration
Version: unspecified
Platform: All
OS/Version: Solaris 11/Nevada
Status: NEW
http://bugs.grommit.com/show_bug.cgi?id=355
Summary: scm hooks should prevent the creation of new tags or
branches in the gate.
Product: SCM Migration
Version: unspecified
Platform: All
OS/Version: Solaris 11/Nevada
Hi,
I'm trying to update the SCM Migration Project task list on genunix.org.
There is a pointer to a list of gatekeeper tools:
http://www.genunix.org/wiki/index.php/gateTools
There are two columns on this table that have data in them: Port and Done.
Does anyone know the meaning of the columns
Rich tried posting to the temporary list that Ken had set up, which
didn't work, so he asked me to forward this. I think after this
message we can all go back to using scm-migration-dev.
mike
--- Forwarded Message
Subject: Re: thoughts about 'buglist' script
From:Richard Lowe
To:
> "Ken" == Ken Erickson writes:
Ken> So, I am re-sending this because for some reason the
Ken> scm-migration-dev list is broken for me and won't send my
Ken> emails...thinks I'm not on the list
Your outgoing mail appears as from ken.erickson at sun.com, but you've
registered as kene at eng.s
So, while thinking about modifying the buglist gate script, I
was thinking of an overall architectural issue, namely email
notification of changes to the gate.
We currently have teamware send email to all gatelings whenever
a putback or undo occurs. This email is also archived in a mailbox
format
20 matches
Mail list logo
