* Re: commitinfo script to check policy, issue warnings (and/orabort commit)
2001-05-14 13:54 commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
@ 2001-05-14 17:45 ` Mark Mitchell
2001-05-16 0:57 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
` (3 subsequent siblings)
4 siblings, 0 replies; 23+ messages in thread
From: Mark Mitchell @ 2001-05-14 17:45 UTC (permalink / raw)
To: rittle, rittle; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-14 13:54 commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
2001-05-14 17:45 ` commitinfo script to check policy, issue warnings (and/orabort commit) Mark Mitchell
@ 2001-05-16 0:57 ` Alexandre Oliva
2001-05-16 1:31 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Gerald Pfeifer
2001-05-18 11:40 ` commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
2001-05-16 1:38 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
` (2 subsequent siblings)
4 siblings, 2 replies; 23+ messages in thread
From: Alexandre Oliva @ 2001-05-16 0:57 UTC (permalink / raw)
To: rittle; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-16 0:57 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
@ 2001-05-16 1:31 ` Gerald Pfeifer
2001-05-18 11:43 ` Loren James Rittle
2001-05-18 11:46 ` Loren James Rittle
2001-05-18 11:40 ` commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
1 sibling, 2 replies; 23+ messages in thread
From: Gerald Pfeifer @ 2001-05-16 1:31 UTC (permalink / raw)
To: Mark Mitchell, Alexandre Oliva; +Cc: rittle, rittle, gcc
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-16 1:31 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Gerald Pfeifer
@ 2001-05-18 11:43 ` Loren James Rittle
2001-05-18 11:46 ` Loren James Rittle
1 sibling, 0 replies; 23+ messages in thread
From: Loren James Rittle @ 2001-05-18 11:43 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-16 1:31 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Gerald Pfeifer
2001-05-18 11:43 ` Loren James Rittle
@ 2001-05-18 11:46 ` Loren James Rittle
1 sibling, 0 replies; 23+ messages in thread
From: Loren James Rittle @ 2001-05-18 11:46 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-16 0:57 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
2001-05-16 1:31 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Gerald Pfeifer
@ 2001-05-18 11:40 ` Loren James Rittle
2001-05-19 18:46 ` Alexandre Oliva
1 sibling, 1 reply; 23+ messages in thread
From: Loren James Rittle @ 2001-05-18 11:40 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-18 11:40 ` commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
@ 2001-05-19 18:46 ` Alexandre Oliva
2001-05-20 10:17 ` commitinfo script to check policy, issue warnings (and/orabort commit) Mark Mitchell
0 siblings, 1 reply; 23+ messages in thread
From: Alexandre Oliva @ 2001-05-19 18:46 UTC (permalink / raw)
To: rittle; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/orabort commit)
2001-05-19 18:46 ` Alexandre Oliva
@ 2001-05-20 10:17 ` Mark Mitchell
2001-05-24 6:15 ` Loren James Rittle
0 siblings, 1 reply; 23+ messages in thread
From: Mark Mitchell @ 2001-05-20 10:17 UTC (permalink / raw)
To: aoliva; +Cc: rittle, gcc
>>>>> "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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/orabort commit)
2001-05-20 10:17 ` commitinfo script to check policy, issue warnings (and/orabort commit) Mark Mitchell
@ 2001-05-24 6:15 ` Loren James Rittle
0 siblings, 0 replies; 23+ messages in thread
From: Loren James Rittle @ 2001-05-24 6:15 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-14 13:54 commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
2001-05-14 17:45 ` commitinfo script to check policy, issue warnings (and/orabort commit) Mark Mitchell
2001-05-16 0:57 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
@ 2001-05-16 1:38 ` Alexandre Oliva
2001-05-18 11:49 ` Loren James Rittle
2001-05-16 6:38 ` Gerald Pfeifer
2001-05-16 13:31 ` commitinfo script to check policy, issue warnings (and/or abort commit) Marc Espie
4 siblings, 1 reply; 23+ messages in thread
From: Alexandre Oliva @ 2001-05-16 1:38 UTC (permalink / raw)
To: rittle; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-16 1:38 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
@ 2001-05-18 11:49 ` Loren James Rittle
2001-05-18 12:58 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Joseph S. Myers
0 siblings, 1 reply; 23+ messages in thread
From: Loren James Rittle @ 2001-05-18 11:49 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-18 11:49 ` Loren James Rittle
@ 2001-05-18 12:58 ` Joseph S. Myers
2001-05-18 13:24 ` Loren James Rittle
0 siblings, 1 reply; 23+ messages in thread
From: Joseph S. Myers @ 2001-05-18 12:58 UTC (permalink / raw)
To: rittle; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-18 12:58 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Joseph S. Myers
@ 2001-05-18 13:24 ` Loren James Rittle
0 siblings, 0 replies; 23+ messages in thread
From: Loren James Rittle @ 2001-05-18 13:24 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-14 13:54 commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
` (2 preceding siblings ...)
2001-05-16 1:38 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
@ 2001-05-16 6:38 ` Gerald Pfeifer
2001-05-16 9:24 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
2001-05-18 12:14 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Loren James Rittle
2001-05-16 13:31 ` commitinfo script to check policy, issue warnings (and/or abort commit) Marc Espie
4 siblings, 2 replies; 23+ messages in thread
From: Gerald Pfeifer @ 2001-05-16 6:38 UTC (permalink / raw)
To: rittle, Alexandre Oliva; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-16 6:38 ` Gerald Pfeifer
@ 2001-05-16 9:24 ` Alexandre Oliva
2001-05-18 12:14 ` commitinfo script to check policy, issue warnings (and/or abortcommit) Loren James Rittle
1 sibling, 0 replies; 23+ messages in thread
From: Alexandre Oliva @ 2001-05-16 9:24 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: rittle, gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abortcommit)
2001-05-16 6:38 ` Gerald Pfeifer
2001-05-16 9:24 ` commitinfo script to check policy, issue warnings (and/or abort commit) Alexandre Oliva
@ 2001-05-18 12:14 ` Loren James Rittle
1 sibling, 0 replies; 23+ messages in thread
From: Loren James Rittle @ 2001-05-18 12:14 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-14 13:54 commitinfo script to check policy, issue warnings (and/or abort commit) Loren James Rittle
` (3 preceding siblings ...)
2001-05-16 6:38 ` Gerald Pfeifer
@ 2001-05-16 13:31 ` Marc Espie
2001-05-16 15:12 ` Branko
2001-05-17 20:18 ` Loren James Rittle
4 siblings, 2 replies; 23+ messages in thread
From: Marc Espie @ 2001-05-16 13:31 UTC (permalink / raw)
To: gcc
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...
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-16 13:31 ` commitinfo script to check policy, issue warnings (and/or abort commit) Marc Espie
@ 2001-05-16 15:12 ` Branko
2001-05-17 6:07 ` Marc Espie
2001-05-17 20:18 ` Loren James Rittle
1 sibling, 1 reply; 23+ messages in thread
From: Branko @ 2001-05-16 15:12 UTC (permalink / raw)
To: gcc
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-16 15:12 ` Branko
@ 2001-05-17 6:07 ` Marc Espie
2001-05-17 12:08 ` Branko
0 siblings, 1 reply; 23+ messages in thread
From: Marc Espie @ 2001-05-17 6:07 UTC (permalink / raw)
To: brane, gcc
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: commitinfo script to check policy, issue warnings (and/or abort commit)
2001-05-16 13:31 ` commitinfo script to check policy, issue warnings (and/or abort commit) Marc Espie
2001-05-16 15:12 ` Branko
@ 2001-05-17 20:18 ` Loren James Rittle
2001-05-17 22:22 ` Fergus Henderson
1 sibling, 1 reply; 23+ messages in thread
From: Loren James Rittle @ 2001-05-17 20:18 UTC (permalink / raw)
To: gcc
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'.
^ permalink raw reply [flat|nested] 23+ messages in thread