[rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Rudy Gevaert]

Just to inform you about my descision.
Please to the necesary to fix this issue. 

----- Forwarded message from Rudy Gevaert <rudy@gnu.org> -----

Date: Wed, 24 Dec 2003 10:24:49 -0500
From: Rudy Gevaert <rudy@gnu.org>
To: Richard Stallman <rms@gnu.org>
Cc: savannah-hackers@gnu.org
Subject: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]

On Wed, Dec 24, 2003 at 10:18:23AM -0500, Richard Stallman wrote:
> Would you please fix this, and ack to me?

I looked at it and it seems that those files were symlinks to other
files in a different project.

I don't know who set this up, but it was a wrong thing to do.

I won't make the symlinks as it only brings problems, like now.


-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

----- End forwarded message -----

-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Thien-Thi Nguyen]

Rudy Gevaert <rudy@gnu.org> writes:

   Just to inform you about my descision.
   Please to the necesary to fix this issue. 

what is the name of the cvs module containing the files in question?
can people do a "cvs checkout" on this module in the usual way?

if it is not a "proper cvs module" (with an entry in some
CVSROOT/modules file), what is the name of the containing project?

i think we can update the instructions for building emacs from cvs if we
know these small pieces of information.

thi

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Rudy Gevaert]

On Thu, Dec 25, 2003 at 10:24:15AM -0500, Thien-Thi Nguyen wrote:
> Rudy Gevaert <rudy@gnu.org> writes:
> 
>    Just to inform you about my descision.
>    Please to the necesary to fix this issue. 
> 
> what is the name of the cvs module containing the files in question?
> can people do a "cvs checkout" on this module in the usual way?
> 
> if it is not a "proper cvs module" (with an entry in some
> CVSROOT/modules file), what is the name of the containing project?
> 
> i think we can update the instructions for building emacs from cvs if we
> know these small pieces of information.

Ok.


regex.c,v -> /cvsroot/gnulib/gnulib/regex.c,v
regex.h,v -> /cvsroot/gnulib/gnulib/regex.h,v

The files can be found in the project "gnulib", module "gnulib".

Note, that these files link to the files on the OLD savannah system.
Those directories don't excist anymore.

-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Thien-Thi Nguyen]

   From: Rudy Gevaert <rudy@gnu.org>
   Date: Thu, 25 Dec 2003 13:21:16 -0500

   The files can be found in the project "gnulib", module "gnulib".

thanks.

for anyone interested, here is a simple script to make regex.[hc]
available when checking out emacs from cvs:

  # usage: sh -ex cvs-update
  emacsroot=`pwd`
  cd ..
  cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
      checkout gnulib
  cd $emacsroot
  cvs update
  cd src
  rm -f regex.[hc]
  ln -s ../../gnulib/regex.h
  ln -s ../../gnulib/regex.c

it presumes you have the disk space to completely check out gnulib,
and that gnulib and ${emacsroot} are sibling directories.

thi

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[David Kastrup]

Thien-Thi Nguyen <ttn@glug.org> writes:

> for anyone interested, here is a simple script to make regex.[hc]
> available when checking out emacs from cvs:
> 
>   # usage: sh -ex cvs-update
>   emacsroot=`pwd`
>   cd ..
>   cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
>       checkout gnulib
>   cd $emacsroot
>   cvs update
>   cd src
>   rm -f regex.[hc]
>   ln -s ../../gnulib/regex.h
>   ln -s ../../gnulib/regex.c
> 
> it presumes you have the disk space to completely check out gnulib,

Any way to do this without this presumption?  Would

cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
        checkout gnulib/regex.{c,h}

do the trick in the script?

And presuming that it does: will an update on the whole Emacs
directory update those two files via their symlinks, from their
respective repositories?  Probably not, right?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Thien-Thi Nguyen]

   From: David Kastrup <dak@gnu.org>
   Date: 25 Dec 2003 23:55:13 +0100

   Any way to do this without this presumption?  Would

   cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
	   checkout gnulib/regex.{c,h}

   do the trick in the script?

i don't know if cvs expands {c,h} properly but if separated into two
distinct commands i'm sure that would work:

gnulib_cvsroot=':ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib'
cvs -d $gnulib_cvsroot checkout gnulib/regex.h
cvs -d $gnulib_cvsroot checkout gnulib/regex.c

for some, disk space savings is probably not as important as bandwidth
savings: 5872 KB for all of gnulib vs 212 KB for only regex.[ch].

   And presuming that it does: will an update on the whole Emacs
   directory update those two files via their symlinks, from their
   respective repositories?  Probably not, right?

correct (hence wrapping the "cvs update" operation w/ this script).
the limitation lies w/ cvs, which operates on a directory-oriented
basis, and does not handle multiple CVSROOT in one logical operation,
at least the last time i probed its failure modes in depth (~1999).
the recent change in deployment to use chroot is even more reason to
do things client-side, ugly as it may appear initially.

thi

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@glug.org>
> Date: Fri, 26 Dec 2003 02:40:27 -0500
> 
>    cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
> 	   checkout gnulib/regex.{c,h}
> 
>    do the trick in the script?
> 
> i don't know if cvs expands {c,h} properly but if separated into two
> distinct commands i'm sure that would work:

I think {c,h} is expanded by the shell, so CVS simply sees two
arguments.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Thien-Thi Nguyen]

   Date: Fri, 26 Dec 2003 12:01:08 +0200
   From: "Eli Zaretskii" <eliz@elta.co.il>

   I think {c,h} is expanded by the shell, so CVS simply sees two
   arguments.

you're right.  i'm on drugs (or vms) for too long...

thi

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Thien-Thi Nguyen]

   From: David Kastrup <dak@gnu.org>
   Date: 25 Dec 2003 23:55:13 +0100

   cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
	   checkout gnulib/regex.{c,h}

fyi, i just tried this and it works w/ cvs 1.11 -- cool!

thi

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[David Kastrup]

Thien-Thi Nguyen <ttn@glug.org> writes:

>    From: David Kastrup <dak@gnu.org>
>    Date: 25 Dec 2003 23:55:13 +0100
> 
>    cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
> 	   checkout gnulib/regex.{c,h}
> 
> fyi, i just tried this and it works w/ cvs 1.11 -- cool!

CVS has nothing to with it at all.  Brace expansion is done already
by the shell.  The above is completely equivalent to

    cvs -d :ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib \
 	   checkout gnulib/regex.c gnulib/regex.h

Because I did not trust CVS in that regard, I had not written
gnulib/regexp.\[ch] which  would have had to be expanded by CVS
(without the backslash, it would have become a filename glob and that
can't be expanded before the files are there).

Even this mistrust may be misapplied since CVS _has_ to support
globbing itself (because of interpreting .cvsignore files, for one
thing).  However, a cursory glance through the man and info pages has
left me in the dark about whether patterns would be allowed in the
checkout command.

So I used brace expansion which bypasses CVS altogether.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Richard Stallman]

    The files can be found in the project "gnulib", module "gnulib".

    Note, that these files link to the files on the OLD savannah system.
    Those directories don't excist anymore.

Is there any way, with the current Savannah system, that we can
make regex.[ch] in Emacs automatically reflect those in gnulib?
Perhaps to have something that follows changes made in gnulib
and checks them in in Emacs?

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Eli Zaretskii]

> Date: Thu, 25 Dec 2003 09:50:32 -0500
> From: Rudy Gevaert <rudy@gnu.org>
> 
> Just to inform you about my descision.
> Please to the necesary to fix this issue. 

If symlinks are not the right thing to do, what is?  Checking out
regex.[ch] from their CVS and checking them into the Emacs CVS?  I
thought the links were used to avoid the need to resync the two
repositories manually; is there a better way to do that?

TIA

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Rudy Gevaert]

On Thu, Dec 25, 2003 at 10:21:45PM +0200, Eli Zaretskii wrote:
> If symlinks are not the right thing to do, what is?  Checking out
> regex.[ch] from their CVS and checking them into the Emacs CVS?  I

Yes

> thought the links were used to avoid the need to resync the two
> repositories manually; is there a better way to do that?

That could be.  I don't know who set up those symlinks.  In our
previous configuration it was possible.  Now, every project runs in a
chroot.  Linking outside this chroot doesn't seem to be the right
thing to do.

I even doubt if it is possible.  If it is, I could be that this breaks
(or could be exploited) the chroot environment.

-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Kim F. Storm]

Rudy Gevaert <rudy@gnu.org> writes:

> On Thu, Dec 25, 2003 at 10:21:45PM +0200, Eli Zaretskii wrote:
> > If symlinks are not the right thing to do, what is?  Checking out
> > regex.[ch] from their CVS and checking them into the Emacs CVS?  I
> 
> Yes

Since there are _vital_ branch and release tagging information in the
old regex.[ch] files related to GNU emacs, it would be inadequate to
just commit the latest version of those files into the emacs
repository.

The only proper solution is to _copy_ the two ,v files directly (on
the CVS server) into the emacs repository, to preserve consistency &
history.

> 
> > thought the links were used to avoid the need to resync the two
> > repositories manually; is there a better way to do that?
> 
> That could be.  I don't know who set up those symlinks.  In our
> previous configuration it was possible.  Now, every project runs in a
> chroot.  Linking outside this chroot doesn't seem to be the right
> thing to do.
> 
> I even doubt if it is possible.  If it is, I could be that this breaks
> (or could be exploited) the chroot environment.

I don't think it is worth it.  The symlinks were a hack whose time has
gone...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Rudy Gevaert]

On Fri, Dec 26, 2003 at 01:19:51AM +0100, Kim F. Storm wrote:

> Since there are _vital_ branch and release tagging information in the
> old regex.[ch] files related to GNU emacs, it would be inadequate to
> just commit the latest version of those files into the emacs
> repository.
> 
> The only proper solution is to _copy_ the two ,v files directly (on
> the CVS server) into the emacs repository, to preserve consistency &
> history.

Are you asking that I copy them? 

I'm surely willing to do it once...

-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Kai Grossjohann]

storm@cua.dk (Kim F. Storm) writes:

> The only proper solution is to _copy_ the two ,v files directly (on
> the CVS server) into the emacs repository, to preserve consistency &
> history.

I vaguely remember that it "works" to use different CVS repositories
for different directories.  That is, you have a directory foo where
foo/CVS/Root specifies one repository and a subdir of foo, foo/bar,
where foo/bar/CVS/Root specifies a different repository.  Then, doing
"cvs update" from foo will update both foo and foo/bar from their
respective repositories.

That might be a workable approach for maintaining consistency on the
client side.

Kai

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Kim F. Storm]

Kai Grossjohann <kai@emptydomain.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > The only proper solution is to _copy_ the two ,v files directly (on
> > the CVS server) into the emacs repository, to preserve consistency &
> > history.
> 
> I vaguely remember that it "works" to use different CVS repositories
> for different directories.  

I think you need to do this through the CVSROOT/Modules file, and it
doesn't support different repositories, only different projects in the
same repository.  With the new chroot security, I would think that
each project has its own repository, and thus cannot share stuff like
that.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Richard Stallman]

    The only proper solution is to _copy_ the two ,v files directly (on
    the CVS server) into the emacs repository, to preserve consistency &
    history.

This would sync them up, now.  However, we would like to make sure
they remain in sync.  I have an idea for how to do that:

1. Do something to prohibit commits to these two files, in Emacs.

2. Have a cron job which copies the master files from gnulib to Emacs
once per hour.

Rudy, can this be done?

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Rudy Gevaert]

On Fri, Dec 26, 2003 at 11:13:45PM -0500, Richard Stallman wrote:

> 1. Do something to prohibit commits to these two files, in Emacs.
> 
> 2. Have a cron job which copies the master files from gnulib to Emacs
> once per hour.

> Rudy, can this be done?

I can do (2), but have no idea how (1) can be done (maybe setting
group writer permissions off?)

Just ack and I'll do (2)
-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Jason Rumney]

Rudy Gevaert <rudy@gnu.org> writes:

> On Fri, Dec 26, 2003 at 11:13:45PM -0500, Richard Stallman wrote:
> 
> > 1. Do something to prohibit commits to these two files, in Emacs.
> > 
> > 2. Have a cron job which copies the master files from gnulib to Emacs
> > once per hour.
> 
> > Rudy, can this be done?
> 
> I can do (2), but have no idea how (1) can be done (maybe setting
> group writer permissions off?)

A commitinfo script should work, even if setting permissions does not.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Kim F. Storm]

Rudy Gevaert <rudy@gnu.org> writes:

> On Fri, Dec 26, 2003 at 11:13:45PM -0500, Richard Stallman wrote:
> 
> > 1. Do something to prohibit commits to these two files, in Emacs.
> > 
> > 2. Have a cron job which copies the master files from gnulib to Emacs
> > once per hour.
> 
> > Rudy, can this be done?
> 
> I can do (2), but have no idea how (1) can be done (maybe setting
> group writer permissions off?)
> 
> Just ack and I'll do (2)

Can you please copy the files as is for now (asap), so we can have a
fully functional emacs repository.  We can then find the proper way to
syncronize the files later.


As it has been pointed out by several people, the version of regex
that we use in emacs is not really the "official" gnulib version, and
by looking at the cvs log from the last 4-5 years, it seems to me that
every change to regex.c is done by someone involved in emacs development.

I wonder if there are other projects which actually uses that version
of regex; if there are none, or if emacs is really the only major
project using it, I think it makes more sense to maintain it in the
emacs project, and not in the gnulib project where it currently
resides.  Does anybody know what other projects use it?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Rudy Gevaert]

On Sat, Dec 27, 2003 at 10:58:14PM +0100, Kim F. Storm wrote:
> Rudy Gevaert <rudy@gnu.org> writes:
> > Just ack and I'll do (2)
> 
> Can you please copy the files as is for now (asap), so we can have a
> fully functional emacs repository.  We can then find the proper way to
> syncronize the files later.

Done
-- 
Rudy Gevaert                rudy@gnu.org		
Web page                    http://www.webworm.org
GNU/Linux for schools       http://www.nongnu.org/glms
Savannah hacker             http://savannah.gnu.org
		                        

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Sam Steingold]

> * Kim F. Storm <fgbez@phn.qx> [2003-12-27 22:58:14 +0100]:
>
> I wonder if there are other projects which actually uses that version
> of regex; if there are none, or if emacs is really the only major
> project using it, I think it makes more sense to maintain it in the
> emacs project, and not in the gnulib project where it currently
> resides.  Does anybody know what other projects use it?

CLISP (http://clisp.cons.org) comes with regexp.[ch] of 1994.
they are used only if the libc does not provide its own regexp.
I wonder if Emacs could do the same, i.e., rely on the OS.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Please wait, MS Windows are preparing the blue screen of death.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Sat, 27 Dec 2003 17:06:21 -0500
> 
> CLISP (http://clisp.cons.org) comes with regexp.[ch] of 1994.
> they are used only if the libc does not provide its own regexp.
> I wonder if Emacs could do the same, i.e., rely on the OS.

I'm not sure my memory isn't failing me, but there could be issues
with non-ASCII characters support in regexps, since Emacs has its own
internal representation of non-ASCII, perhaps different from the
system library's.

But I agree it's generally a good idea to allow for a system regex to
be used, especially if I'm wrong and the issue I mentioned doesn't
really exist.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Miles Bader]

On Sun, Dec 28, 2003 at 08:10:00AM +0200, Eli Zaretskii wrote:
> But I agree it's generally a good idea to allow for a system regex to
> be used, especially if I'm wrong and the issue I mentioned doesn't
> really exist.

I'm not sure what you mean by `system regex', but emacs does certainly depend
on non-standard features of the GNU regex code, namely the interface which
allows searching across the buffer-gap.  So emacs can't use any `system
regex' that doesn't define this interface.

AFAIK, the new regular-expression implementation in glibc actually _has_ that
interface, but it works in a completely stupid (and essentially useless) way,
so emacs shouldn't use it -- but that situation might be hard to detect using
standard autoconf methods.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Richard Stallman]

    AFAIK, the new regular-expression implementation in glibc actually _has_ that
    interface, but it works in a completely stupid (and essentially useless) way,

Is there any chance we could fix it to work well, so that Emacs could
use that version?

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Kenichi Handa]

In article <ufzf54gnb.fsf@elta.co.il>, Eli Zaretskii <eliz@elta.co.il> writes:
> I'm not sure my memory isn't failing me, but there could be issues
> with non-ASCII characters support in regexps, since Emacs has its own
> internal representation of non-ASCII, perhaps different from the
> system library's.

You are right.  In addition, Emacs at least needs these
features in regex.

(1) local syntax table
(2) category table

---
Ken'ichi HANDA
handa@m17n.org

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Richard Stallman]

    CLISP (http://clisp.cons.org) comes with regexp.[ch] of 1994.
    they are used only if the libc does not provide its own regexp.
    I wonder if Emacs could do the same, i.e., rely on the OS.

This won't work for Emacs.  It uses many nonstandard features
of this regex.[ch] version.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Richard Stallman]

    > 1. Do something to prohibit commits to these two files, in Emacs.
    > 
    > 2. Have a cron job which copies the master files from gnulib to Emacs
    > once per hour.

    > Rudy, can this be done?

    I can do (2), but have no idea how (1) can be done 

Does anyone know enough about CVS to tell us?

						       (maybe setting
    group writer permissions off?)

How about if you try that experiment now?  In a few minutes, you can
see if it really works.

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>     > 1. Do something to prohibit commits to these two files, in Emacs.
>     > 
>     > 2. Have a cron job which copies the master files from gnulib to Emacs
>     > once per hour.
> 
>     > Rudy, can this be done?
> 
>     I can do (2), but have no idea how (1) can be done 
> 
> Does anyone know enough about CVS to tell us?

Tweaking the ownership/perms of the RCS ,v files will probably not
help, because CVS operates by copying and renaming.  Instead, we need
a line in CVSROOT/commitinfo, something like this:

   emacs/src   /path/to/specialized/protection-script.sh

(It starts at the beginning of the line, of course, I'm just indenting
for clarity here.)  Then 'protection-script.sh' would look like this:

   #!/bin/sh
   
   # The first argument is always the absolute path to the repository
   # subdir.  Shift past that to get to the individual files.
   shift

   for FNAME in $@; do
     if [ ${FNAME} = regex.c -o ${FNAME} = regex.h ]; then
       echo "Cannot commit to ${FNAME} in this repository."
       exit 1
     fi
   done

   exit 0

Hope this helps,
-Karl

Re: [rudy@gnu.org: Re: [Savannah-hackers] [teirllm@dms.auburn.edu: Re: emacs/src/regex.c]]

[Richard Stallman]

Thanks for suggesting this method.