Re: [CVS] regex.[ch] missing in CVS checkout

Re: [CVS] regex.[ch] missing in CVS checkout

[Miles Bader]

"Martin Lüthi" <answer@tnoo.net> writes:
> Both regex.[ch] are missing in today's cvs checkout. Fortunately I
> had an old copy laying around.

I think regex.[ch] were(are?) symlinks in the CVS repository to the
`master copies' (something which CVS is supposed to handle properly),
because they are actually shared with other projects.

However I presume the new chroot'd savannah isn't compatible with this,
so something else must be done.

-Miles
-- 
Run away!  Run away!

Re: [CVS] regex.[ch] missing in CVS checkout

[Miles Bader]

"Martin L?thi" <answer@tnoo.net> writes:
> Both regex.[ch] are missing in today's cvs checkout. Fortunately I
> had an old copy laying around.

I think regex.[ch] were(are?) symlinks in the CVS repository to the
`master copies' (something which CVS is supposed to handle properly),
because they are actually shared with other projects.

However I presume the new chroot'd savannah isn't compatible with this,
so something else must be done.

-Miles
-- 
I'd rather be consing.

Re: [CVS] regex.[ch] missing in CVS checkout

[Kai Grossjohann]

Miles Bader <miles@gnu.org> writes:

> I think regex.[ch] were(are?) symlinks in the CVS repository to the
> `master copies' (something which CVS is supposed to handle properly),
> because they are actually shared with other projects.

I guess that a workaround is to check out the right project, then
perform the symlinks on the client side.  Does anyone know which
project is this?  It wasn't "gnu-regex", which is a Java thing.

tia,
Kai

Re: [CVS] regex.[ch] missing in CVS checkout

[Luc Teirlinck]

Kai Grossjohann wrote:

   I guess that a workaround is to check out the right project, then
   perform the symlinks on the client side.  Does anyone know which
   project is this?  It wasn't "gnu-regex", which is a Java thing.

They are symlinked to gnulib/regex [ch] (not to be confused with
gnulib/src/regex [ch]) according to an old message by Stefan.

Sincerely,

Luc.

Re: [CVS] regex.[ch] missing in CVS checkout

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> They are symlinked to gnulib/regex [ch] (not to be confused with
> gnulib/src/regex [ch]) according to an old message by Stefan.

Thank you.

My Emacs checkout is in ~/work/gnu/emacs.  I did:

    cd ~/work/gnu
    cvs -d $FOO co gnulib
    cd emacs/src
    ln -s ../../gnulib/regex.c
    ln -s ../../gnulib/regex.h

Now the Emacs compile is happily chugging along.

$FOO is what the CVS instructions say for anon checkout of the gnulib
project.

I suspect that my workaround is (much!) less than perfect because I
suspect weird behavior on next "cvs up -dP" or "cvs ci".  But I
haven't tested it, yet.

Kai

Re: [CVS] regex.[ch] missing in CVS checkout

[Miles Bader]

On Thu, Dec 25, 2003 at 05:55:11PM +0100, Kai Grossjohann wrote:
> > They are symlinked to gnulib/regex [ch] (not to be confused with
> > gnulib/src/regex [ch]) according to an old message by Stefan.
> 
> My Emacs checkout is in ~/work/gnu/emacs.  I did:
...
> $FOO is what the CVS instructions say for anon checkout of the gnulib
> project.

This is one way to do it, however it's obviously a pain for people checking
out emacs.

Another way would be to do what used to be done, and simply keep separate
copies of regex.[ch] in emacs, merging back and forth with the official
gnulib copies as necessary.

If changes to regex.[ch] occur somewhat rarely, I'd say the latter method is
better.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: [CVS] regex.[ch] missing in CVS checkout

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> Another way would be to do what used to be done, and simply keep separate
> copies of regex.[ch] in emacs, merging back and forth with the official
> gnulib copies as necessary.

Note that there are already two versions of regex.[ch]: gnulib/regex.[ch]
and gnulib/lib/regex.[ch].

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [CVS] regex.[ch] missing in CVS checkout

[Karl Fogel]

Miles Bader <miles@gnu.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > What should be done is to copy $CVSROOT/gnulib/regex.[ch],v (and not
> > $CVSROOT/gnulib/lib/regex.[ch],v) to $CVSROOT/emacs/src.
> > Maybe moving them would work just as well, but copying is safer.
> 
> This got done a while ago... (just got back from vacation?)
> 
> There was some talk about also adding a CVS hook to prevent
> modifications, but I don't know if anything got done.

In case this wasn't done, but someone with the requisite access wants
to do it, a method was posted here:

   http://mail.gnu.org/archive/html/emacs-devel/2003-12/msg00663.html

(Mentioning it because posts made during holidays can sometimes drop
into the ether...)

-Karl

Re: [CVS] regex.[ch] missing in CVS checkout

[Stefan Monnier]

> I think regex.[ch] were(are?) symlinks in the CVS repository to the
> `master copies' (something which CVS is supposed to handle properly),
> because they are actually shared with other projects.

Yes, and this doesn't work any more.
What should be done is to copy $CVSROOT/gnulib/regex.[ch],v (and not
$CVSROOT/gnulib/lib/regex.[ch],v) to $CVSROOT/emacs/src.
Maybe moving them would work just as well, but copying is safer.


        Stefan

Re: [CVS] regex.[ch] missing in CVS checkout

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> What should be done is to copy $CVSROOT/gnulib/regex.[ch],v (and not
> $CVSROOT/gnulib/lib/regex.[ch],v) to $CVSROOT/emacs/src.
> Maybe moving them would work just as well, but copying is safer.

This got done a while ago... (just got back from vacation?)

There was some talk about also adding a CVS hook to prevent
modifications, but I don't know if anything got done.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: [CVS] regex.[ch] missing in CVS checkout

[Kim F. Storm]

Karl Fogel <kfogel@floss.red-bean.com> writes:

> Miles Bader <miles@gnu.org> writes:
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > > What should be done is to copy $CVSROOT/gnulib/regex.[ch],v (and not
> > > $CVSROOT/gnulib/lib/regex.[ch],v) to $CVSROOT/emacs/src.
> > > Maybe moving them would work just as well, but copying is safer.

Note that Stefan actually says "moving" is ok.

That indicates to me that emacs is really the only package
using that specific version of regex.* -- which is also the
idea you get if you look at the revision log for the files.

So is the really any reason to keep those file in sync
between gnulib and emacs repositories -- or could we
just continue to maintain the files under the emacs
repository (where they were copied some time ago) ?


> > 
> > This got done a while ago... (just got back from vacation?)
> > 
> > There was some talk about also adding a CVS hook to prevent
> > modifications, but I don't know if anything got done.
> 
> In case this wasn't done, but someone with the requisite access wants
> to do it, a method was posted here:
> 

I still don't see why this is necessary if emacs is the only
package using those files ... it must be possible to find out
if there are other packages using it (were there other symlinks
to them which have been broken?)

Maybe the original files could be made "read-only" using Karl's
code, in case we want to keep (an obsolete copy) of them in
gnulib.  IMO, it would probably be better just to cvs remove
them from the gnulib repository (provided emacs was the only 
package using them).

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

Re: [CVS] regex.[ch] missing in CVS checkout

[Richard Stallman]

    In case this wasn't done, but someone with the requisite access wants
    to do it, a method was posted here:

       http://mail.gnu.org/archive/html/emacs-devel/2003-12/msg00663.html

    (Mentioning it because posts made during holidays can sometimes drop
    into the ether...)

I would guess that only savannah-hackers can do any of these things.
So if it has not been done yet, please remind savannah-hackers.
(They may need to ask the sysadmins.)

Re: [CVS] regex.[ch] missing in CVS checkout

[Karl Fogel]

storm@cua.dk (Kim F. Storm) writes:
> > > There was some talk about also adding a CVS hook to prevent
> > > modifications, but I don't know if anything got done.
> 
> I still don't see why this is necessary if emacs is the only
> package using those files ... it must be possible to find out
> if there are other packages using it (were there other symlinks
> to them which have been broken?)

I think the idea was to prevent diverging changes?

That is, if these versions of regex.[ch] are truly frozen in the Emacs
repository, while their maintenance continues on separate copies in
another repository, then that's not too bad a situation.  But if
people start modifying them in the Emacs repository, in ways that
diverge from what's happening in their "master" repository, then we
have an accidental fork on our hands, and sorting it all out years
later can be a real hassle.

Thus, the hook's job would be to block any change to these files in
the Emacs repository, and print a warning that they should instead be
modified in their master repository (perhaps by branching from the
point where Emacs's frozen copies came from).  Emacs could be updated
periodically from the master repository, as appropriate.

I'm not advocating for or against this strategy, by the way, merely
trying to answer your question.

(Or there could be some totally different reason, that someone more
familiar with the situation can explain.)

-Karl

Re: [CVS] regex.[ch] missing in CVS checkout

[Kim F. Storm]

Karl Fogel <kfogel@floss.red-bean.com> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > > > There was some talk about also adding a CVS hook to prevent
> > > > modifications, but I don't know if anything got done.
> > 
> > I still don't see why this is necessary if emacs is the only
> > package using those files ... it must be possible to find out
> > if there are other packages using it (were there other symlinks
> > to them which have been broken?)
> 
> I think the idea was to prevent diverging changes?

Yes I understand that.


However nobody seems to answer my basic question:

ARE THERE ANY OTHER PACKAGES (besides emacs) WHICH USES THOSE FILES?


If emacs is the only packages which uses these files, why maintain
them separately from emacs?  

All changes to those files for the last 5 years are related to emacs,
so I doubt any other package is using them.  I don't want us to solve
a problem which isn't there!

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

Re: [CVS] regex.[ch] missing in CVS checkout

[Richard Stallman]

    Note that Stefan actually says "moving" is ok.

    That indicates to me that emacs is really the only package
    using that specific version of regex.* -- which is also the
    idea you get if you look at the revision log for the files.

It indicates that maybe Stefan thinks Emacs is the only package using
those files.  We cannot draw a stronger conclusion than that.

Is Emacs really the only package using those files?
How would we find out?

Re: [CVS] regex.[ch] missing in CVS checkout

[Karl Fogel]

storm@cua.dk (Kim F. Storm) writes:
> However nobody seems to answer my basic question:
> 
> ARE THERE ANY OTHER PACKAGES (besides emacs) WHICH USES THOSE FILES?

It may be that no one here knows.

> If emacs is the only packages which uses these files, why maintain
> them separately from emacs?  
> 
> All changes to those files for the last 5 years are related to emacs,
> so I doubt any other package is using them.  I don't want us to solve
> a problem which isn't there!

Sure, that makes sense.

I don't know how to find out whether they're being used by other
packages, which depend on them staying in the original repository.
Not sure where you should ask to get an authoritative answer, either,
and there's no particular reason why this list would be the place.

-Karl