This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: commitinfo script to check policy, issue warnings (and/or abort commit)
- To: gcc at gcc dot gnu dot org
- Subject: Re: commitinfo script to check policy, issue warnings (and/or abort commit)
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Thu, 17 May 2001 18:47:02 -0500 (CDT)
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <200105142054.f4EKsGw18471@latour.rsch.comm.mot.com>
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'.