This is the mail archive of the
mailing list for the GCC project.
Re: Reapply patch lost during recent "blind import" of libtool
In article <email@example.com>,
Alexandre Oliva <firstname.lastname@example.org> writes:
>>> If the script only issues a warning message to the person who did the
>>> check-in (and to `email@example.com'?) that's good. If it actually
>>> prevents the check-in, I think that's too strong.
>> As posted, the script prevented check-in since import was the
>> documented way to update those files.
> Besides, it's easy enough to do an import instead of a check-in.
Yes, imports are never checked. So someone trying to cheat the rules
can *always* import. Is it OK for the checker script to make commits
on some files fail, if it is made clear how to use import to cheat the
> But I understand it might be more convenient to be able to just
> check-in. But then, when you got the warning, it would be too late
If it isn't a little painful to circumvent the correct process, I feel
we are right back where we were before attempting to improve the
> Could the exit status of the script depend on some
> command-line argument given to cvs commit?
Unfortunately, under CVS, the filter that checks commits does not get
any client-provided arguments.
> Another alternative I like is to get the commit script to test the
> version numbers, at least in ltconfig and ltmain.sh, and make sure
> they're modified between the existing version and the one about to be
> committed, and, if they don't differ, issue a hard error. This would
> guarantee that locally-modified files are clearly marked as such.
I can see why you want that, but that is a tad harder to do I am
afraid. The commitinfo script has direct access to the names of files
to be changed and indirect access to the contents of the files to be
changed. I don't know that one can legally run 'cvs update
-rUNKNOWN-WHAT-GOES-HERE -p' to get a copy of the file to compare against.