commitinfo script to check policy, issue warnings (and/or abort commit)

commitinfo script to check policy, issue warnings (and/or abort commit)

[Loren James Rittle]

I wrote:

> In addition to any English description, a good place to document this
> policy might be in CVSROOT/commitinfo and a supporting script. [...]

I have finished updating this proposed commitinfo script based on
Gerald Pfeifer, Alexandre Oliva and Mark Mitchell's comments.  The
script has been completed based upon the initial idea and fully tested
in my environment, but someone with shell access to gcc.gnu.org will
have to take over from here and build the contents of
CVSROOT/commitinfo based on the sample in the comment.  Notice that
the GCC Steering Committee can set policy along two lines.

Although I think it is a cool idea, I did not incorporate the
suggestion to open an X11 connection back to client to ask questions
since that would require other policy changes (someone could add this
later).  I also think it might be a good idea if this script used data
from external files instead of being fairly hard-coded (again, someone
could change it later - and the current method has the benefit of
being very straightforward code).

If we want to force people to use `cvs import' to bring libtool into
our source tree (i.e. prevent_commit=0), then this documentation
should appear in http://gcc.gnu.org/codingconventions.html:

Here is a correct way to use CVS vendor branches with the import
policy rules for libtool (this example for libtool only, but
config.guess, etc should be similar):

1. Create an empty directory (i.e. do not work in a checked-out CVS
   working tree).  Populate it with upgraded libtool files taken from
   the master repository on subversion.gnu.org.

2. Run: cvs import /cvs/gcc SUBVERSION LIBTOOL_RELEASE_NUMBER
   within the directory populated in step 1.

3. Ignore any merge warnings the first time this is done.

4. Run: cvs admin -bSUBVERSION ltconfig ltmain.sh libtool.m4 ltcf-*.sh
   at the top level of a checked-out CVS working tree.

If we want to just warn when libtool files are changed
(i.e. prevent_commit=1), then the existing documentation should be OK.
The person's commit will succeed, but they will have been given a
message explaining why they might have broken protocol with a pointer
to more information.  Enabling e-mail (i.e. send_mail=0) only makes
sense when we do not prevent the commit.

Regards,
Loren

#!/bin/sh
#
# This commitinfo script warns a commiter of violations of the policy
# encoded in http://gcc.gnu.org/codingconventions.html section
# "Upstream packages" and suggests actions to be handled outside CVS.
# Upon request, it may be configured to never prevent a commit and to
# send mail to gcc@gcc.gnu.org.
#
# Here are the sample contents of CVSROOT/commitinfo to support this
# script (the exact paths must be fully checked by the installer with
# knowledge of gcc.gnu.org's CVS repository layout):
#
# /cvs/gcc/boehm-gc check-gcc-commit
# /cvs/gcc/fastjar check-gcc-commit
# /cvs/gcc/.* true
# /cvs/gcc check-gcc-commit

# GCC Steering Committee settable values
# (all booleans using UNIX shell conventions that 0 is true)

# Should this script prevent the commit if it detects a violation?
prevent_commit=0

# Should this script send e-mail upon issuing a warning?
send_mail=1
send_mail_to=nobody #gcc@gcc.gnu.org

# Run environment settable values

PATH=/bin:/usr/bin

# NO settable values past this point

# Handle warnings for commits into special subdirectories.  This is
# really just a memory aid since it is not wrong to commit these
# changes.
for i in `basename $1`; do case $i in
  boehm-gc)
    echo "WARNING: Patches should be sent to boehm@acm.org, but it was"
    echo "WARNING: acceptable to check them in the GCC CVS tree before"
    echo "WARNING: getting them installed in the master tree."
    exit 0;;
  fastjar)
    echo "WARNING: The master sources are at fastjar.sourceforge.net."
    echo "WARNING: Local patches should be sent upstream, but it was"
    echo "WARNING: acceptable to check them in the GCC CVS tree before"
    echo "WARNING: getting them installed in the master tree."
    exit 0;;
esac; done

message_emitted=1
important_message_emitted=1
imported_files_committed=

shift; for i in $*; do case $i in
  config.guess|config.sub|ltconfig|ltmain.sh|libtool.m4|ltcf-*.sh)
    echo "WARNING: $i should only be upgraded from the related external"
    echo "WARNING: master source repository using 'cvs import'."
    imported_files_committed="$imported_files_committed $i"
    important_message_emitted=0
    message_emitted=0;;
  *)
    echo "WARNING: $i should be synchronized with the corresponding file"
    echo "WARNING: in the src repository at sources.redhat.com."
    message_emitted=0;;
esac; done

if (exit $message_emitted); then
  echo "WARNING: See http://gcc.gnu.org/codingconventions.html for details."
fi

if (exit $important_message_emitted); then
  if (exit $send_mail); then
    mail -s 'CVS commit operation to imported files' $send_mail_to <<EOF
Someone committed a change to the following file(s):
$imported_files_committed

This is usually not the correct procedure to update these file(s).
See http://gcc.gnu.org/codingconventions.html for complete details.
EOF
  fi
  if (exit $prevent_commit); then exit 1; fi
fi

exit 0

Re: commitinfo script to check policy, issue warnings (and/orabort commit)

[Mark Mitchell]

Thanks for doing this!

Gerald, would you look this over, and install it if it looks OK to
you?

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Alexandre Oliva]

On May 14, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

> for i in `basename $1`; do case $i in

basename is not portable.  I suggest `echo "$1" | sed 's,.*/,,'' instead.

>   boehm-gc)
>     echo "WARNING: Patches should be sent to boehm@acm.org, but it was"
>     echo "WARNING: acceptable to check them in the GCC CVS tree before"
>     echo "WARNING: getting them installed in the master tree."

I heard Hans wanted the GCC CVS tree to become the official repository
of boehm-gc.  I'm not sure this is already official.

> if (exit $message_emitted); then
>   echo "WARNING: See http://gcc.gnu.org/codingconventions.html for details."
> fi

I don't think we should prevent commits, but if check-ins can be
aborted at this time with ^C, I suggest telling the user so and giving
him/her like 30 seconds to decide whether to break the convention or
not.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Gerald Pfeifer]

On Mon, 14 May 2001, Mark Mitchell wrote:
> Gerald, would you look this over, and install it if it looks OK to
> you?

Yes, I'll take care of it -- with the help of Alexandre and whoever
else wants to help.

On 16 May 2001, Alexandre Oliva wrote:
>> for i in `basename $1`; do case $i in
> basename is not portable.  I suggest `echo "$1" | sed 's,.*/,,'' instead.

Given that this script is only supposed to run on the CVS server with
the GCC master tree, is this a concern? All modern systems I am aware
of have basename.

> I heard Hans wanted the GCC CVS tree to become the official repository
> of boehm-gc.  I'm not sure this is already official.

There are some final details that are being checked, so it's not official,
but there is a good chance it will become "soon".

> I don't think we should prevent commits, but if check-ins can be
> aborted at this time with ^C, I suggest telling the user so and giving
> him/her like 30 seconds to decide whether to break the convention or
> not.

Yes, that sounds like an excellent compromise (to start with). And, that
notification email to gcc@gcc.gnu.org should be sent whenever a commit
does happen.

Loren, could you please make these minor changes and send a new version?
I'll then take care of the rest -- praying that I won't block commits to
the entire tree! :-O

Thanks for following this path and helping us to address this issue that
thouroughly now!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Alexandre Oliva]

One more nit.

On May 14, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

> shift; for i in $*; do case $i in

Instead of $*, I'd rather use ${1+"$@"}

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Gerald Pfeifer]

On Mon, 14 May 2001, Loren James Rittle wrote:
> If we want to force people to use `cvs import' to bring libtool into
> our source tree (i.e. prevent_commit=0), then this documentation
> should appear in http://gcc.gnu.org/codingconventions.html:
>
> Here is a correct way to use CVS vendor branches with the import
> policy rules for libtool (this example for libtool only, but
> config.guess, etc should be similar):
>
> 1. Create an empty directory (i.e. do not work in a checked-out CVS
>    working tree).  Populate it with upgraded libtool files taken from
>    the master repository on subversion.gnu.org.
>
> 2. Run: cvs import /cvs/gcc SUBVERSION LIBTOOL_RELEASE_NUMBER
>    within the directory populated in step 1.
>
> 3. Ignore any merge warnings the first time this is done.
>
> 4. Run: cvs admin -bSUBVERSION ltconfig ltmain.sh libtool.m4 ltcf-*.sh
>    at the top level of a checked-out CVS working tree.

Well, as far as I understood, we don't want to absolutely enforce this
rule, but strongly recommend it, so it would make sense to add such a
note to codingconventions.html anyway, wouldn't it? Alexandre?

(If Alexandre agrees, I'd say just go ahead and change the web page
according to your proposal. Thanks!)

Gerald

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Alexandre Oliva]

On May 16, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On Mon, 14 May 2001, Loren James Rittle wrote:
>> If we want to force people to use `cvs import' to bring libtool into
>> our source tree (i.e. prevent_commit=0), then this documentation
>> should appear in http://gcc.gnu.org/codingconventions.html:

> Well, as far as I understood, we don't want to absolutely enforce this
> rule, but strongly recommend it, so it would make sense to add such a
> note to codingconventions.html anyway, wouldn't it? Alexandre?

Yep, sounds reasonable to me.  But I'm not so sure about how to get
things imported into a branch, for example.  So I'd probably end up
just checking in new versions.  The important thing, to me, is not to
enforce import as opposed to commit, but to make it clear that
versions should be brought over from gnu/config and libtool, as
opposed to installing local changes, to avoid divergence and confusion
about versions labeled with the same version number doing different
things.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Marc Espie]

import is all very fine in theory. There are two large stumbling blocks 
though, which make it VERY annoying.

* the cvs program is a complete nitwit when it comes to merging stuff imported 
on vendor branches. It's very good at resurrecting stuff that's been 
completely forgotten about, and that you eradicated yourself. The suggestions
it gives for facilitating the merge are erroneous at best.

* cvs can't import to anything but HEAD.

* cvs can't import to anything but HEAD.

* cvs can't import to anything but HEAD.

* cvs can't import to anything but HEAD.


The first issue is already a large pain. I've been routinely using vendor
branches to import gcc/gdb/binutils to OpenBSD, and believe me, it's a real
pain, thanks to the size of those projects (try bringing back the testsuite
from 2.8 when it isn't include in 2.95, for instance, or go on removing 
umpteen files that have been eradicated since then and that `import' insists
on bringing back to life.

The second issue is completely brain-dead. It just means that in many cases,
you have the choice of creating an entire new tree for experimental work,
or forgetting about import entirely.


Trying to do advanced things with cvs is likely to bring major pain. There is
no decent free alternative right now, but getting cute with cvs is a MAJOR
loss...

This is just a warning...

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Branko]

Marc Espie wrote:

>* cvs can't import to anything but HEAD.
>
>* cvs can't import to anything but HEAD.
>
>* cvs can't import to anything but HEAD.
>
>* cvs can't import to anything but HEAD.
>
Yes, it can. Use `cvs import -b':

$ cvs --help import
Usage: cvs import [-d] [-k subst] [-I ign] [-m msg] [-b branch]
    [-W spec] repository vendor-tag release-tags...
        -d      Use the file's modification time as the time of import.
        -k sub  Set default RCS keyword substitution mode.
        -I ign  More files to ignore (! to reset).
        -b bra  Vendor branch id.
        -m msg  Log message.
        -W spec Wrappers specification line.


-- 
Brane Čibej
    home:   <brane@xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane@acm.org>            http://www.acm.org/

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Marc Espie]

In article < 3B02FB5E.4040705@xbc.nu > you write:
>Marc Espie wrote:
>
>>* cvs can't import to anything but HEAD.
>>
>>* cvs can't import to anything but HEAD.
>>
>>* cvs can't import to anything but HEAD.
>>
>>* cvs can't import to anything but HEAD.
>>
>Yes, it can. Use `cvs import -b':
>
>$ cvs --help import
>Usage: cvs import [-d] [-k subst] [-I ign] [-m msg] [-b branch]
>    [-W spec] repository vendor-tag release-tags...
>        -d      Use the file's modification time as the time of import.
>        -k sub  Set default RCS keyword substitution mode.
>        -I ign  More files to ignore (! to reset).
>        -b bra  Vendor branch id.
>        -m msg  Log message.
>        -W spec Wrappers specification line.

Did you actually TRY using it ?

I just rechecked my facts, by putting two files under cvs, and having branches
at the point I wanted.


cvs import -b   does not deal with symbolic tags. It wants numeric stuff.
Assume I create a branch using cvs -b tag, as I usually do.


I end up with this:
cvs status: Examining .
===================================================================
File: a                 Status: Up-to-date

   Working revision:    1.3     Thu May 17 12:57:22 2001
   Repository revision: 1.3     /home/espie/.cvsroot/voyons/a,v
   Sticky Tag:          REL2 (branch: 1.3.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: b                 Status: Up-to-date

   Working revision:    1.1     Thu May 17 12:59:01 2001
   Repository revision: 1.1     /home/espie/.cvsroot/voyons/b,v
   Sticky Tag:          REL2 (branch: 1.1.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

Here's the complete list of rev for both files:

RCS file: /home/espie/.cvsroot/voyons/a,v
Working file: a
head: 1.3
branch:
locks: strict
access list:
symbolic names:
        REL2: 1.3.0.2
        EXP1: 1.2.0.2
        espie2: 1.1.1.1
        espie: 1.1.1
=============================================================================

RCS file: /home/espie/.cvsroot/voyons/b,v
Working file: b
head: 1.1
branch:
locks: strict
access list:
symbolic names:
        REL2: 1.1.0.2



Now, tell me how to achieve cvs import -b REL2 ?
If you can do it, I'm interested. As far as I've tried, I can't do it.

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Branko]

Marc Espie wrote:

>
>Did you actually TRY using it ?
>
>I just rechecked my facts, by putting two files under cvs, and having branches
>at the point I wanted.
>
Umm. Good point. I forgot `cvs import -b' can only create branches off 
of the root of the tree.


-- 
Brane Čibej
    home:   <brane@xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane@acm.org>            http://www.acm.org/

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Loren James Rittle]

In article < 200105162031.WAA17964@quatramaran.ens.fr > you write:
>import is all very fine in theory. There are two large stumbling blocks 
>though, which make it VERY annoying.

You raise some interesting points about CVS import.  In case it was
not clear from context, for the record: I was talking about using
import to bring the libtool files (currently 8 files) and possibly a
few other few top-level files that are suppose to be obtained from
other sources instead of changed locally.  I.e. in terms of scale, we
would not have hit the types of problems you hit trying to import gcc
or other massive code bases into OpenBSD's source base.

> * cvs can't import to anything but HEAD.

Since you repeated this statement 4 times, I must correct you.
Strictly speaking, cvs import doesn't import to HEAD or any other
established branch used to maintain local changes.  It *always*
imports to things called vendor branchs.

Regards,
Loren

PS, the issue is now moot since it appears that we don't wish to use
cvs import in the gcc tree.  I.e. although the word "import" was/is
used in some documentation related to how we will handle our source
tree for gcc at gcc.gnu.org, it was never meant to imply the actual
use of `cvs import'.

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Fergus Henderson]

On 17-May-2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:
> Strictly speaking, cvs import doesn't import to HEAD or any other
> established branch used to maintain local changes.  It *always*
> imports to things called vendor branchs.

Although cvs imports to vendor branches, the changes that you've
imported (in fact even worse, only *some* of the changes) still show up
when you do `cvs checkout -A', so in that sense they are on the head.
See recent thread on info-cvs@gnu.org:
< http://mail.gnu.org/pipermail/info-cvs/2001-May/014765.html > and
< http://mail.gnu.org/pipermail/info-cvs/2001-April/014141.html >.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Loren James Rittle]

In article < or7kzhraiy.fsf@guarana.lsd.ic.unicamp.br >, Alexandre Oliva <aoliva@redhat.com> writes:

> On May 14, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:
>> for i in `basename $1`; do case $i in

> basename is not portable.  I suggest `echo "$1" | sed 's,.*/,,'' instead.

OK.  Even though the code only runs on Red Hat servers - changed.

> I heard Hans wanted the GCC CVS tree to become the official repository
> of boehm-gc.  I'm not sure this is already official.

OK.  I think we can change the script as the situation is reported in
gcc@gcc.gnu.org.

>> if (exit $message_emitted); then
>> echo "WARNING: See http://gcc.gnu.org/codingconventions.html for details."
>> fi

> I don't think we should prevent commits, but if check-ins can be
> aborted at this time with ^C, I suggest telling the user so and giving
> him/her like 30 seconds to decide whether to break the convention or
> not.

This stuck me as a good idea.  I have studied this issue a bit.
Informing the user they have 30 seconds to abort and then sleeping for
30 seconds does not work!  If the user aborts, the abort is captured
by the local client and then 30 seconds after the procedure started,
the server proceeds to commit the change.

I also investigated halting the commitinfo script with a read.  As
expected, there is no pipe back to the CVS client.

It looks like a passive warning system is the best I can do with
available resources.

Regards,
Loren

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Loren James Rittle]

In article < Pine.BSF.4.33.0105161025550.21904-100000@deneb.dbai.tuwien.ac.at >,
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> All modern systems I am aware of have basename.

That was my thinking when I hacked it out, but portability is a good
thing.

> Yes, that sounds like an excellent compromise (to start with). And, that
> notification email to gcc@gcc.gnu.org should be sent whenever a commit
> does happen.

> Loren, could you please make these minor changes and send a new version?

I was waiting for final input to drain.  We appear to be at that point
now.  Changes forthcoming.

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Loren James Rittle]

In article < Pine.BSF.4.33.0105161025550.21904-100000@deneb.dbai.tuwien.ac.at >,
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> Yes, that sounds like an excellent compromise (to start with).

Oops, it would be a good compromise but it breaks the client/server
model exposed by CVS.  Can't do it (easily or at all) unless X11
connection was permitted by the client - I can't see opening that can
for something that was suppose to just check policy.

> And, that notification email to gcc@gcc.gnu.org should be sent
> whenever a commit does happen.

OK, the script handles this but I will change the message to make more
sense in light of final requirements.

Regards,
Loren

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Loren James Rittle]

In article < orsni5pu3k.fsf@guarana.lsd.ic.unicamp.br >,
Alexandre Oliva <aoliva@redhat.com> writes:

> Instead of $*, I'd rather use ${1+"$@"}

I won't even ask why...  OK.

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Loren James Rittle]

In article < Pine.BSF.4.33.0105161536200.33725-100000@taygeta.dbai.tuwien.ac.at >,
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

>> 2. Run: cvs import /cvs/gcc SUBVERSION LIBTOOL_RELEASE_NUMBER
>> within the directory populated in step 1.

> Well, as far as I understood, we don't want to absolutely enforce this
> rule, but strongly recommend it, so it would make sense to add such a
> note to codingconventions.html anyway, wouldn't it? Alexandre?

OK, my current understanding is that the idea of using `cvs import' in
the gcc tree has not gone over too well.

> (If Alexandre agrees, I'd say just go ahead and change the web page
> according to your proposal. Thanks!)

Given the feedback, I'm inclined to nix the use of `cvs import'.
Instead, strongly suggest that any change (related to libtool) which
is being checked in must have come from the libtool source base and
that a violation should be corrected ASAP by submitting to the libtool
source base.

I really want to put this thing to bed..

Regards,
Loren

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Joseph S. Myers]

On Fri, 18 May 2001, Loren James Rittle wrote:

> In article < orsni5pu3k.fsf@guarana.lsd.ic.unicamp.br >,
> Alexandre Oliva <aoliva@redhat.com> writes:
> 
> > Instead of $*, I'd rather use ${1+"$@"}
> 
> I won't even ask why...  OK.

I suggest simply using "$@".  While robustness in the face of spaces in 
filenames is a good idea (although no-one should try to commit such 
filenames to the GCC tree), allowing for non-POSIX shells that don't 
handle "$@" properly is surely an irrelevance for a script run on 
gcc.gnu.org.

Could the script also give a warning if someone commits through the old
"egcs" link rather than the "gcc" directory?  I'd like to see these
residual egcs references go away more from gcc-cvs.  The script 
contrib/newcvsroot allows someone to convert easily.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: commitinfo script to check policy, issue warnings (and/or abortcommit)

[Loren James Rittle]

In < Pine.LNX.4.33.0105182054180.28875-100000@kern.srcf.societies.cam.ac.uk >,
"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> I suggest simply using "$@".

OK.

> Could the script also give a warning if someone commits through the
> old "egcs" link rather than the "gcc" directory?

I had thought of this issue briefly.  In fact, whomever does final
deployment would have to fix these sample paths (taken from a header
comment in the last posted version of the script):

/cvs/gcc/boehm-gc check-gcc-commit
/cvs/gcc/fastjar check-gcc-commit
/cvs/gcc/.* true
/cvs/gcc check-gcc-commit

At the very least, I sort of knew that each line had to expand into
two pieces:

/cvs/gcc/gcc/.* true
/cvs/gcc/egcs/.* true

The script itself only gets a relative path within the module/
directory not the name it was called though.

The obvious way to encode this is:

/cvs/gcc/gcc check-gcc-commit
/cvs/gcc/egcs check-gcc-commit-nix-egcs-wrapper

where check-gcc-commit-nix-egcs-wrapper is (something like):

#!/bin/sh

check-gcc-commit "$@" || exit 1
echo WARNING: Please update your tree to change s/egcs/gcc/ in all
echo WARNING: CVS/Repository files.  See contrib/newcvsroot for a way
echo WARNING: to avoid having to checkout an entirely new tree.
exit 0 # At some point change this to a 1

> I'd like to see these residual egcs references go away more from
> gcc-cvs.  The script contrib/newcvsroot allows someone to convert
> easily.

Sounds good.  Haven't people been given more than long enough to
convert their trees over to the new name?  (However, I note that I'm
one to talk, since 3 out of 4 of my working trees all point to egcs
and not gcc.)

Given the wide availability of the conversion script (everyone with a
checked out tree has a copy), I don't see why the nix-egcs wrapper
should not be installed along that outdated name's path.

Thanks for raising this issue.

Regards,
Loren

Re: commitinfo script to check policy, issue warnings (and/or abort commit)

[Alexandre Oliva]

On May 18, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

> Informing the user they have 30 seconds to abort and then sleeping for
> 30 seconds does not work!  If the user aborts, the abort is captured
> by the local client and then 30 seconds after the procedure started,
> the server proceeds to commit the change.

:-(

Not even if you attempt to write a relatively long message back to the
client after the 30 seconds wait?  I'd hope that, if writing this
message fails, the client has disconnected, so the script could tell
the server to not commit the message.

This assumes the script is writing directly to the client, or at least
to some buffer that will stop accepting data as soon as it notices the
other end is gone.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: commitinfo script to check policy, issue warnings (and/orabort commit)

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> On May 18, 2001, Loren James Rittle
    Alexandre> <rittle@latour.rsch.comm.mot.com> wrote:

    >> Informing the user they have 30 seconds to abort and then
    >> sleeping for 30 seconds does not work!  If the user aborts, the
    >> abort is captured by the local client and then 30 seconds after
    >> the procedure started, the server proceeds to commit the
    >> change.

    Alexandre> :-(

Gentlemen --

  In my opinion, we are working too hard to enforce this policy,
through what are probably relatively frail means.  I think
notification is good enough.  There are lots of other aspects of our
coding standards that are more important (like that functions have
comments, or that code be tested before check-in) that we rely
entirely on the honor system for.

  If we're going to be in the business of writing complex scripts to
check things on check-in, I'd rather we be writing the
documentation-checker.  I'm not joking actually -- use javadoc style
comments, maybe, and then make sure they're present.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: commitinfo script to check policy, issue warnings (and/orabort commit)

[Loren James Rittle]

In article < 20010520101145G.mitchell@codesourcery.com >,
Mark Mitchell <mark@codesourcery.com> writes:

>   In my opinion, we are working too hard to enforce this policy,
> through what are probably relatively frail means.

For the record, I had to agree with this position.  I think the
version posted some time ago was basically good enough for someone to
use on the CVS server with a little "last minute" tuning based on the
environment.  But wait until after the 3.0 release and I will apply
all the posted tweaks (at least those that survived additional
commentary) and simplify down to use as a basic reminder.  The sending
of e-mail and locking-out does not seem to suit our honor-system very
well.  I think most reasonable people will following any additional
steps they are reminded about or learn of for the first time.

Regards,
Loren