Checkout of Emacs CVS through firewall

Checkout of Emacs CVS through firewall

[Juanma Barranquero]

(Slightly off-topic)

Does anyone know how to do an anonymous checkout of Emacs from Savannah
when you're below a fascistic firewall (I mean, port 80 and 443 and no
much else...)

                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

Juanma Barranquero <jmbarranquero@wke.es> writes:
> Does anyone know how to do an anonymous checkout of Emacs from Savannah
> when you're below a fascistic firewall (I mean, port 80 and 443 and no
> much else...)

That's how my work is...

subversions.gnu.org used to run a CVS pserver on port 443, but I assume
that disappeared with pserver generally.

Some other possibilities:

 * If you've got `tla' handy (there's a debian package for it in
   testing/unstable), you can use my arch branch of emacs, which is
   available via http:

      http://sourcecontrol.net/~miles/miles@gnu.org--gnu-2004

 * There's a port-443 ssh server running on fp-ssh.gnu.org; you could
   could transfer the source tree in two steps (ssh to fencepost,
   checkout emacs there, make tarball, sftp it back to your fascist
   system), or even do something fancy and set up some sort of tunnel.

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Wed, 09 Jun 2004 18:08:18 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> subversions.gnu.org used to run a CVS pserver on port 443, but I assume
> that disappeared with pserver generally.

It seems so.

> Some other possibilities:
> 
>  * If you've got `tla' handy (there's a debian package for it in
>    testing/unstable), you can use my arch branch of emacs, which is
>    available via http:
> 
>       http://sourcecontrol.net/~miles/miles@gnu.org--gnu-2004

Thanks! I'll try that.

I've downloaded a tla binary for Windows, and I've done 

  tla register-archive http://sourcecontrol.net/~miles/miles@gnu.org--gnu-2004

which I think is a prerequisite.  I don't know how to go from here... 
(I'll read the docs, I just can do it right now).

Is that a read-only access, or read-write?  Is the branch synchronized
with the CVS trunk at given intervals, or continuously (via a script or
whatever)?


                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Stefan Monnier]

> Does anyone know how to do an anonymous checkout of Emacs from Savannah
> when you're below a fascistic firewall (I mean, port 80 and 443 and no
> much else...)

First step is to complain loudly and request port 22 to be opened.
Once this is done, you should be able to find a `tla´ package somewhere and
checkout the Arch tree of Emacs


        Stefan

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Wed, Jun 09, 2004 at 11:42:27AM +0200, Juanma Barranquero wrote:
> I've downloaded a tla binary for Windows, and I've done 
> 
>   tla register-archive http://sourcecontrol.net/~miles/miles@gnu.org--gnu-2004
> 
> which I think is a prerequisite.  I don't know how to go from here... 
> (I'll read the docs, I just can do it right now).

Um; I'm not sure if there are funny issues with windows or not.

Before doing anything I'd recommend you make a `revision library' -- it
isn't necessary, but it makes life much nicer (it's basically a cache for
revisions).  You can do that like:

   $ mkdir -p $SOME_PATH/arch/revlib
   $ tla my-revision-library $SOME_PATH/arch/revlib
   $ tla library-config --greedy --sparse $SOME_PATH/arch/revlib

[where $SOME_PATH/arch/revlib is an arbitrary directory name]

Optionally, you can setup gnupg to check library signatures, but you can
skip that for now.

Then you get the tree; emacs is big so this will take a long time unless you
have a fast connection:

   $ cd $MY_SRC_DIR
   $ tla get miles@gnu.org--gnu-2004/emacs--cvs-trunk--0 emacs

[That will put emacs into $MY_SRC_DIR/emacs]

> Is that a read-only access, or read-write?

It's read-only.  If you want read-write access, you'd need ssh access to
fencepost, but you could probably use port 443 on fp-ssh.gnu.org for that
(that's what I use from work).  

I've never done R/W access for anyone else, so it would take some time to
work out what to do, but it might be an interesting experiment -- I'd like
for it to be possible for others to commit via arch.

[An alternative which is slightly more `archy' would be for you to set up
your own archive with your own branch of emacs, arrange for it to be
anonymously accessible, and then periodically ask for it to be merged into
the cvs-synchronized branch -- ideally that would via some sort of automatic
mechanism e.g. a mail daemon, but of course that requires more
infrastructure.]

> Is the branch synchronized with the CVS trunk at given intervals, or
> continuously (via a script or whatever)?

It's synchronized via a script that I run manually, but I run it pretty
often (every time I log into fencepost mostly) as it's just one command.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Wed, Jun 09, 2004 at 06:13:43AM -0400, Stefan Monnier wrote:
> First step is to complain loudly and request port 22 to be opened.

ha ha, I see you don't work at a large company with a dedicated `network
division'.  Where I work, they have a one word vocabularly: "no" -- wait
scratch that, actually, they just never reply.  So zero words.  Very
efficient.

Luckily even they are forced to allow http access, and well, once any port
at all is opened, that's that.

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Wed, 9 Jun 2004 08:40:39 -0400
Miles Bader <miles@gnu.org> wrote:

> Um; I'm not sure if there are funny issues with windows or not.

tla seems to work OK, though it looks a bit... "unpolished"?

> Before doing anything I'd recommend you make a `revision library' -- it

OK, done.

   $ cd $MY_SRC_DIR
   $ tla get miles@gnu.org--gnu-2004/emacs--cvs-trunk--0 emacs

I'm currently doing that, and it's *slow*, even on a fast connection :(

> I've never done R/W access for anyone else, so it would take some time to
> work out what to do, but it might be an interesting experiment -- I'd like
> for it to be possible for others to commit via arch.

If I ever get to speed with arch we can try to make it work.

> [An alternative which is slightly more `archy' would be for you to set up
> your own archive with your own branch of emacs, arrange for it to be
> anonymously accessible, and then periodically ask for it to be merged into
> the cvs-synchronized branch -- ideally that would via some sort of automatic
> mechanism e.g. a mail daemon, but of course that requires more
> infrastructure.]

Yeah, I imagined the "proper" way was to do something like that (that's
one of the fortes of arch, isn't it?), but is too complex for my current
needs.

> It's synchronized via a script that I run manually, but I run it pretty
> often (every time I log into fencepost mostly) as it's just one command.

More than enough.  What I want to do is synchronize my local copy at
work once or twice a day, at most.  Currently I'm forced to get updates
from home via a USB memory stick.

Thanks a lot for your help,

                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

[I left the list out of Cc: by accident]

On 09 Jun 2004 06:13:43 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> First step is to complain loudly and request port 22 to be opened.

If I were able to be that convincing, I'd get CVS access... :)

> Once this is done, you should be able to find a `tla´ package somewhere and
> checkout the Arch tree of Emacs

I'm trying that.  For the moment being, I'm less than impressed with
arch/tla:

D:\...\archs> tla make-archive lektu@terra.es--test-2004 d:\data\archs\test-2004

/home/johannes/Projects/tla/win32/src/tla/libarch/pfs-fs.c:87:botched invariant
    !!uri
PANIC: exiting on botched invariant

(Yes, I now know I should use forward slashes...) I'm sure Arch is interesting,
but its Windows support is very weak.  That won't preclude my trying to
use it, though :)


                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Wed, 9 Jun 2004 08:40:39 -0400
Miles Bader <miles@gnu.org> wrote:

> Um; I'm not sure if there are funny issues with windows or not.

Well, after building the sources in-place (I hardly ever use
--installdir), I get:

  C:\bin\emacs\HEAD> tla changes
  * looking for miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-390 to compare with
  * comparing to miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-390
  PANIC: duplicate ids in MOD tree, try tree-lint

and tree-lint shows (not all output):

  C:\bin\emacs\HEAD> tla tree-lint
  These apparent source files lack inventory ids:
  
  bin
  data
  lock
  site-lisp
  
  
  Duplicated ids among each group of files listed here:
  
  leim/makefile	i_08250c45-fa9c-4f39-a175-a0c5c36dd67b
  leim/makefile.w32-in
  
  lib-src/makefile	i_c051bc02-a6de-474b-889a-27f7b2fbbcea
  lib-src/makefile.w32-in
  
  lisp/makefile	i_bd03b562-c58d-4403-99db-c7bccd8c49a0
  lisp/makefile.w32-in
  
  lispintro/makefile	i_d713164a-e683-4ce3-a39e-3bf82f2f82f4
  lispintro/makefile.w32-in
  
  lispref/makefile	i_da68f1c2-536d-4d41-9150-7b01434eda3f
  lispref/makefile.w32-in
  
  man/makefile	i_6e99da59-ad27-4816-82a0-cde9a101efae
  man/makefile.w32-in
  
  etc/icons	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.226
  nt/icons
  
  etc/icons/.arch-ids/=id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.226
  nt/icons/.arch-ids/=id
  
  etc/icons/.arch-ids/emacs.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.227
  nt/icons/.arch-ids/emacs.ico.id
  
  etc/icons/.arch-ids/gnu2a32.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.228
  nt/icons/.arch-ids/gnu2a32.ico.id
  
  etc/icons/.arch-ids/gnu2a32t.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.229
  nt/icons/.arch-ids/gnu2a32t.ico.id
  
  etc/icons/.arch-ids/gnu2b48.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.230
  nt/icons/.arch-ids/gnu2b48.ico.id
  
  etc/icons/.arch-ids/gnu2b48t.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.231
  nt/icons/.arch-ids/gnu2b48t.ico.id
  
  etc/icons/.arch-ids/gnu3b32.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.232
  nt/icons/.arch-ids/gnu3b32.ico.id
  
  etc/icons/.arch-ids/gnu3b32t.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.233
  nt/icons/.arch-ids/gnu3b32t.ico.id
  
  etc/icons/.arch-ids/gnu4g48.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.234
  nt/icons/.arch-ids/gnu4g48.ico.id
  
  etc/icons/.arch-ids/gnu4g48t.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.235
  nt/icons/.arch-ids/gnu4g48t.ico.id
  
  etc/icons/.arch-ids/gnu5w32.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.236
  nt/icons/.arch-ids/gnu5w32.ico.id
  
  etc/icons/.arch-ids/gnu5w32t.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.237
  nt/icons/.arch-ids/gnu5w32t.ico.id
  
  etc/icons/.arch-ids/gnu6w48.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.238
  nt/icons/.arch-ids/gnu6w48.ico.id
  
  etc/icons/.arch-ids/gnu6w48t.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.239
  nt/icons/.arch-ids/gnu6w48t.ico.id
  
  etc/icons/.arch-ids/gnu7.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.240
  nt/icons/.arch-ids/gnu7.ico.id

  etc/icons/.arch-ids/gnu8.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.241
  nt/icons/.arch-ids/gnu8.ico.id
  
  etc/icons/.arch-ids/gnu9.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.242
  nt/icons/.arch-ids/gnu9.ico.id
  
  etc/icons/.arch-ids/hand.cur.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.244
  nt/icons/.arch-ids/hand.cur.id
  
  etc/icons/.arch-ids/sink.ico.id	E_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.243
  nt/icons/.arch-ids/sink.ico.id
  
  etc/icons/emacs.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.227
  nt/icons/emacs.ico
  
  etc/icons/gnu2a32.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.228
  nt/icons/gnu2a32.ico
  
  etc/icons/gnu2a32t.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.229
  nt/icons/gnu2a32t.ico
  
  etc/icons/gnu2b48.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.230
  nt/icons/gnu2b48.ico
  
  etc/icons/gnu2b48t.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.231
  nt/icons/gnu2b48t.ico
  
  etc/icons/gnu3b32.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.232
  nt/icons/gnu3b32.ico
  
  etc/icons/gnu3b32t.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.233
  nt/icons/gnu3b32t.ico
  
  etc/icons/gnu4g48.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.234
  nt/icons/gnu4g48.ico
  
  etc/icons/gnu4g48t.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.235
  nt/icons/gnu4g48t.ico
  
  etc/icons/gnu5w32.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.236
  nt/icons/gnu5w32.ico
  
  etc/icons/gnu5w32t.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.237
  nt/icons/gnu5w32t.ico
  
  etc/icons/gnu6w48.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.238
  nt/icons/gnu6w48.ico
  
  etc/icons/gnu6w48t.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.239
  nt/icons/gnu6w48t.ico
  
  etc/icons/gnu7.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.240
  nt/icons/gnu7.ico
  
  etc/icons/gnu8.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.241
  nt/icons/gnu8.ico
  
  etc/icons/gnu9.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.242
  nt/icons/gnu9.ico
  
  etc/icons/hand.cur	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.244
  nt/icons/hand.cur

  etc/icons/sink.ico	x_Miles_Bader_<miles@gnu.org>_Tue_Jul_29_15:01:20_2003_10113.243
  nt/icons/sink.ico
  
  nt/makefile	i_6f5b23a6-774b-4598-9c29-58235b2b4219
  nt/makefile.w32-in
  
  src/makefile	i_9fd7aba8-f826-4111-b3c0-497a8e7db9a0
  src/makefile.w32-in


                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

Juanma Barranquero <jmbarranquero@wke.es> writes:
> Well, after building the sources in-place (I hardly ever use --installdir), I get:
>
>   C:\bin\emacs\HEAD> tla changes
>   * looking for miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-390 to compare with
>   * comparing to miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-390
>   PANIC: duplicate ids in MOD tree, try tree-lint

There are pretty likely to be some problems if you build-in-place, as I
never do that (and apparently other arch users are the same).

Looking at your list, all the duplicate ids starting with "i_" are due
to that; I'll see what I can do to fix those (part of the problem is
that autoconf doesn't have a useful "strip this comment in the generated
file" syntax).

The rest of the problems (unknown directories "bin", "data", "lock",
"site-lisp"; directory "etc/icons" apparently a copy of "nt/icons") seem
to suggest you're also _installing_ into the source tree.  That's just
brain-dead, don't do that (does the windows makefile advocate this?!?)
-- there's only so much that can be done if you insist on crapping all
over the source tree.

Thanks,

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Thu, 10 Jun 2004 10:33:57 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> There are pretty likely to be some problems if you build-in-place, as I
> never do that (and apparently other arch users are the same).

Well, I've opted now to have a build directory, rsync'ed from the copy I
update from your system.  I don't mind the disk space and I think I'll
probably avoid a lot of trouble.

> Looking at your list, all the duplicate ids starting with "i_" are due
> to that; I'll see what I can do to fix those (part of the problem is
> that autoconf doesn't have a useful "strip this comment in the generated
> file" syntax).

Yeah, nt/configure.bat has no way to do that either.  I'd be necessary
to require yet another tool, like sed or perl, and That's Not Good.

> The rest of the problems (unknown directories "bin", "data", "lock",
> "site-lisp"; directory "etc/icons" apparently a copy of "nt/icons") seem
> to suggest you're also _installing_ into the source tree.  That's just
> brain-dead, don't do that (does the windows makefile advocate this?!?)

No, it doesn't advocate it, and neither does forbid it.  I know some
projects (like GCC) advise against building in place, but I've never
heard such a thing wrt Emacs, and in fact I do it all the time with no
ill effects. "cvs update" just shows there are a few "unknown" (i.e., "?")
directories and files, and that's all.

> -- there's only so much that can be done if you insist on crapping all
> over the source tree.

It seems wise to work *with* the tool and not *against* it, so from now
on I won't do inplace builds on Arch-controled copies :)

Thanks,


                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

Juanma Barranquero <jmbarranquero@wke.es> writes:
>> The rest of the problems (unknown directories "bin", "data", "lock",
>> "site-lisp"; directory "etc/icons" apparently a copy of "nt/icons") seem
>> to suggest you're also _installing_ into the source tree.  That's just
>> brain-dead, don't do that (does the windows makefile advocate this?!?)
>
> No, it doesn't advocate it, and neither does forbid it.  I know some
> projects (like GCC) advise against building in place, but I've never
> heard such a thing wrt Emacs, and in fact I do it all the time with no
> ill effects.

Note that I'm not complaining about _building in-place -- if nothing
else, that's a long-standing Emacs tradition -- but about (apparently)
_installing_ to the source directory, i.e., putting bin/ &c there.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Thu, 10 Jun 2004 17:12:38 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> Note that I'm not complaining about _building in-place -- if nothing
> else, that's a long-standing Emacs tradition -- but about (apparently)
> _installing_ to the source directory, i.e., putting bin/ &c there.

Yes, I understand.  But installing in place is faster, and in the almost
three years I've been doing so daily I never had any trouble at all till
now.

But I'm not complaining either.  Having access to Emacs sources from
your repository is great, and I don't mind in the slightest to have to
rsync before bootstrapping.  I was a bit caught by surprise, that's all.

                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

Juanma Barranquero <jmbarranquero@wke.es> writes:
> Well, after building the sources in-place (I hardly ever use
> --installdir), I get:

Try updating to the latest version; I think I've fixed all the issues
that made building/installing in place annoying.

Thanks,

-Miles
-- 
I'd rather be consing.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Fri, 11 Jun 2004 11:44:28 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> Try updating to the latest version; I think I've fixed all the issues
> that made building/installing in place annoying.

Thanks for taking the effort.

After installing in place, "tla update" works fine.  However, "tla changes"
produces:

  * looking for miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-397 to compare
  with
  * comparing to miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-397
  PANIC: duplicate ids in MOD tree, try tree-lint

and "tla tree-lint" gives:

  These apparent source files lack inventory ids:
  
  etc/DOC
  etc/DOC-X
  leim/leim-list.el
  leim/makefile
  leim/quail/4Corner.el
  leim/quail/ARRAY30.el
  leim/quail/CCDOSPY.el
  leim/quail/ECDICT.el
  leim/quail/ETZY.el
  leim/quail/PY-b5.el
  leim/quail/PY.el
  leim/quail/Punct-b5.el
  leim/quail/Punct.el
  leim/quail/QJ-b5.el
  leim/quail/QJ.el
  leim/quail/SW.el
  leim/quail/TONEPY.el
  leim/quail/ZIRANMA.el
  leim/quail/ZOZY.el
  leim/quail/quick-b5.el
  leim/quail/quick-cns.el
  leim/quail/tsang-b5.el
  leim/quail/tsang-cns.el
  lib-src/DOC
  lib-src/makefile
  lib-src/obj-spd
  lib-src/obj-spd/i386
  lib-src/obj-spd/i386/ctags.exe
  lib-src/obj-spd/i386/ctags.obj
  lib-src/obj-spd/i386/ebrowse.exe
  lib-src/obj-spd/i386/ebrowse.obj
  lib-src/obj-spd/i386/etags.exe
  lib-src/obj-spd/i386/etags.obj
  lib-src/obj-spd/i386/getopt.obj
  lib-src/obj-spd/i386/getopt1.obj
  lib-src/obj-spd/i386/hexl.exe
  lib-src/obj-spd/i386/hexl.obj
  lib-src/obj-spd/i386/make-docfile.exe
  lib-src/obj-spd/i386/make-docfile.obj
  lib-src/obj-spd/i386/movemail.exe
  lib-src/obj-spd/i386/movemail.obj
  lib-src/obj-spd/i386/ntlib.obj
  lib-src/obj-spd/i386/pop.obj
  lib-src/obj-spd/i386/regex.obj
  lisp/Makefile.unix
  lisp/makefile
  lispintro/makefile
  lispref/makefile
  man/makefile
  nt/makefile
  nt/obj-spd
  nt/obj-spd/i386
  nt/obj-spd/i386/addpm.exe
  nt/obj-spd/i386/addpm.obj
  nt/obj-spd/i386/addsection.exe
  nt/obj-spd/i386/addsection.obj
  nt/obj-spd/i386/cmdproxy.exe
  nt/obj-spd/i386/cmdproxy.obj
  nt/obj-spd/i386/ddeclient.exe
  nt/obj-spd/i386/ddeclient.obj
  nt/obj-spd/i386/emacs.res
  nt/obj-spd/i386/preprep.exe
  nt/obj-spd/i386/preprep.obj
  nt/obj-spd/i386/runemacs.exe
  nt/obj-spd/i386/runemacs.obj
  src/makefile
  src/obj-spd
  src/obj-spd/etc
  src/obj-spd/etc/DOC-X
  src/obj-spd/i386
  src/obj-spd/i386/abbrev.obj
  src/obj-spd/i386/alloc.obj
  src/obj-spd/i386/atimer.obj
  src/obj-spd/i386/buffer.obj
  src/obj-spd/i386/bytecode.obj
  src/obj-spd/i386/callint.obj
  src/obj-spd/i386/callproc.obj
  src/obj-spd/i386/casefiddle.obj
  src/obj-spd/i386/casetab.obj
  src/obj-spd/i386/category.obj
  src/obj-spd/i386/ccl.obj
  src/obj-spd/i386/charset.obj
  src/obj-spd/i386/cm.obj
  src/obj-spd/i386/cmds.obj
  src/obj-spd/i386/coding.obj
  src/obj-spd/i386/composite.obj
  src/obj-spd/i386/data.obj
  src/obj-spd/i386/dired.obj
  src/obj-spd/i386/dispnew.obj
  src/obj-spd/i386/doc.obj
  src/obj-spd/i386/doprnt.obj
  src/obj-spd/i386/editfns.obj
  src/obj-spd/i386/emacs.exe
  src/obj-spd/i386/emacs.obj
  src/obj-spd/i386/emacs.res
  src/obj-spd/i386/eval.obj
  src/obj-spd/i386/fileio.obj
  src/obj-spd/i386/filelock.obj
  src/obj-spd/i386/filemode.obj
  src/obj-spd/i386/firstfile.obj
  src/obj-spd/i386/floatfns.obj
  src/obj-spd/i386/fns.obj
  src/obj-spd/i386/fontset.obj
  src/obj-spd/i386/frame.obj
  src/obj-spd/i386/fringe.obj
  src/obj-spd/i386/gmalloc.obj
  src/obj-spd/i386/image.obj
  src/obj-spd/i386/indent.obj
  src/obj-spd/i386/insdel.obj
  src/obj-spd/i386/intervals.obj
  src/obj-spd/i386/keyboard.obj
  src/obj-spd/i386/keymap.obj
  src/obj-spd/i386/lastfile.lib
  src/obj-spd/i386/lastfile.obj
  src/obj-spd/i386/lread.obj
  src/obj-spd/i386/macros.obj
  src/obj-spd/i386/marker.obj
  src/obj-spd/i386/md5.obj
  src/obj-spd/i386/minibuf.obj
  src/obj-spd/i386/print.obj
  src/obj-spd/i386/process.obj
  src/obj-spd/i386/ralloc.obj
  src/obj-spd/i386/regex.obj
  src/obj-spd/i386/region-cache.obj
  src/obj-spd/i386/scroll.obj
  src/obj-spd/i386/search.obj
  src/obj-spd/i386/sound.obj
  src/obj-spd/i386/strftime.obj
  src/obj-spd/i386/syntax.obj
  src/obj-spd/i386/sysdep.obj
  src/obj-spd/i386/temacs.bin
  src/obj-spd/i386/temacs.exe
  src/obj-spd/i386/temacs.map
  src/obj-spd/i386/temacs.pdb
  src/obj-spd/i386/temacs0.lib
  src/obj-spd/i386/temacs1.lib
  src/obj-spd/i386/temacw32.lib
  src/obj-spd/i386/term.obj
  src/obj-spd/i386/termcap.obj
  src/obj-spd/i386/textprop.obj
  src/obj-spd/i386/tparam.obj
  src/obj-spd/i386/undo.obj
  src/obj-spd/i386/unexw32.obj
  src/obj-spd/i386/vm-limit.obj
  src/obj-spd/i386/w32.obj
  src/obj-spd/i386/w32bdf.obj
  src/obj-spd/i386/w32console.obj
  src/obj-spd/i386/w32fns.obj
  src/obj-spd/i386/w32heap.obj
  src/obj-spd/i386/w32inevt.obj
  src/obj-spd/i386/w32menu.obj
  src/obj-spd/i386/w32proc.obj
  src/obj-spd/i386/w32reg.obj
  src/obj-spd/i386/w32select.obj
  src/obj-spd/i386/w32term.obj
  src/obj-spd/i386/w32xfns.obj
  src/obj-spd/i386/window.obj
  src/obj-spd/i386/xdisp.obj
  src/obj-spd/i386/xfaces.obj
  
  
  These explicit ids have no corresponding file:
  
  lisp/.arch-ids/Makefile.in.id
  
  
  Duplicated ids among each group of files listed here:
  
  lib-src/ctags.c	i_8a9b748d-390c-4922-99db-2eeefa921051
  lib-src/etags.c


                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

Juanma Barranquero <jmbarranquero@wke.es> writes:
> and "tla tree-lint" gives:
>
>   These apparent source files lack inventory ids:
>
>   etc/DOC
>   etc/DOC-X
>   leim/leim-list.el
>   leim/makefile

These I understand

>   leim/quail/4Corner.el
>   leim/quail/ARRAY30.el
>   leim/quail/CCDOSPY.el
[... etc ...]

These are annoying; it would be nice if they were built using some sort
of consistent naming convention, but I guess they could be enumerated
as "to be ignored".

>   lib-src/DOC
>   lib-src/makefile

OK

>   lib-src/obj-spd
[... etc ...]

What is "obj-spd"?

There's not much I can do about platform-specific build noise...

[All this is the same annoying crap that has to be done for "clean"
rules; you can see why people like separate build dirs...]

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Fri, 11 Jun 2004 17:51:19 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> >   lib-src/obj-spd
> [... etc ...]
> 
> What is "obj-spd"?

On Windows, the directory for object files can be called:

  oo            # GCC build, non-opt
  oo-spd        # GCC build, optimized
  obj           # MSVC build, non-opt
  obj-spd       # MSVC build, optimized

I don't know why, but I imagine it's to ease testing patches on both
compilers.

> There's not much I can do about platform-specific build noise...

Noise is not a problem.  This was, I think:

  These explicit ids have no corresponding file:
  
  lisp/.arch-ids/Makefile.in.id
  
  
  Duplicated ids among each group of files listed here:
  
  lib-src/ctags.c	i_8a9b748d-390c-4922-99db-2eeefa921051
  lib-src/etags.c

In Un*x environments ctags.c is a link to etags.c, I think; on Windows,
ctags.c is copied from etags.c.

> [All this is the same annoying crap that has to be done for "clean"
> rules; you can see why people like separate build dirs...]

Yes, I understand why.  But my use case is a bit different.  I build
Emacs fairly often, either normal make or bootstrap (in fact I bootstrap
at least daily, just to check that it works), and I never do a release
tarball or pass my build to other people.  So it is *much* faster for me
to build in place; I avoid a lot of copying 'round (it also saves me
disk space, but that is moot).

                                                                Juanma

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Fri, Jun 11, 2004 at 10:40:58AM +0200, Juanma Barranquero wrote:
> After installing in place, "tla update" works fine.  However, "tla changes"
> produces:
> 
>   * looking for miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-397 to compare
>   with
>   * comparing to miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-397
>   PANIC: duplicate ids in MOD tree, try tree-lint

Try again now.

>   These explicit ids have no corresponding file:
>   
>   lisp/.arch-ids/Makefile.in.id

Did lisp/Makefile.in somehow get deleted?!?

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Fri, 11 Jun 2004 19:49:45 -0400, Miles Bader <miles@gnu.org> wrote:

> Try again now.

Yeah, now it works like a charm.

> Did lisp/Makefile.in somehow get deleted?!?

nt/configure.bat contains the following line:

  if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile.in Makefile.unix

I have no idea why.


                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Sat, Jun 12, 2004 at 05:08:49AM +0200, Juanma Barranquero wrote:
> nt/configure.bat contains the following line:
> 
>   if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile.in Makefile.unix
> 
> I have no idea why.

Offhand it sounds like something that should be fixed in nt/configure.bat.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Sat, 12 Jun 2004 00:44:46 -0400, Miles Bader <miles@gnu.org> wrote:

> Offhand it sounds like something that should be fixed in nt/configure.bat.

From revision 1.1, nt/configure.bat has had:

   if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile Makefile.unix

In 1.5, Eli changed it to

   if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile.in Makefile.unix

Curiously, the log says: "Don't copy lisp/Makefile, it doesn't exist;
copy lisp/Makefile.in instead."

I'm going to ask Eli what's the purpose of this line and whether it cold
be changed to really copy, instead of moving.

With respect to installing in place, we're almost there.  Renaming back
Makefile.unix to Makefile.in, I'm able to "tla update" after a
compilation. However, I get a kind of warning:

  These apparent source files lack inventory ids:
  
  etc/DOC-X
  leim/quail/4Corner.el
  leim/quail/ARRAY30.el
  leim/quail/PY-b5.el
  leim/quail/Punct-b5.el
  leim/quail/Punct.el
  leim/quail/QJ-b5.el
  lib-src/DOC
  
  
  * reverting changes
  D   etc/DOC-X
  D   leim/quail/4Corner.el
  D   leim/quail/ARRAY30.el
  D   leim/quail/CTLau-b5.el
  D   leim/quail/CTLau.el
  D   leim/quail/PY-b5.el
  D   leim/quail/Punct-b5.el
  D   leim/quail/Punct.el
  D   leim/quail/QJ-b5.el
  D   lib-src/DOC
  * updating for new patches in archive
  
Is that something that should be fixed/adjusted?


                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Sat, Jun 12, 2004 at 02:55:00PM +0200, Juanma Barranquero wrote:
>   These apparent source files lack inventory ids:
>   
>   etc/DOC-X
>   leim/quail/4Corner.el
>   leim/quail/ARRAY30.el
>   leim/quail/PY-b5.el
>   leim/quail/Punct-b5.el
>   leim/quail/Punct.el
>   leim/quail/QJ-b5.el
>   lib-src/DOC

The ones in leim/... are due to a typo, which I'll fix.

I don't know about etc/DOC-X -- is there really a file called "DOC-X" (that
is "X", not a version number)?

And what is a DOC file doing in lib-src?  AFAIK, DOC should always be in etc/
somwhere.

-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: Checkout of Emacs CVS through firewall

[Miles Bader]

On Sat, Jun 12, 2004 at 09:06:59AM -0400, Miles Bader wrote:
> I don't know about etc/DOC-X -- is there really a file called "DOC-X" (that
> is "X", not a version number)?
> 
> And what is a DOC file doing in lib-src?  AFAIK, DOC should always be in etc/
> somwhere.

Never mind, I saw in the windows makefile where these are created.

I've updated things.

-Miles
-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Sat, 12 Jun 2004 09:06:59 -0400, Miles Bader <miles@gnu.org> wrote:

> The ones in leim/... are due to a typo, which I'll fix.

Ah, OK.

> 
> I don't know about etc/DOC-X -- is there really a file called "DOC-X" (that
> is "X", not a version number)?

Yes, "DOC-X" is its name.

> And what is a DOC file doing in lib-src?  AFAIK, DOC should always be in etc/
> somwhere.

Building Emacs on Windows generates:

  lib-src\DOC
  obj-spd\etc\DOC-X

and the in-place install:

  etc\DOC
  etc\DOC-X

(all identical).

More tla questions:

 - How can get rid of:

   WARNING: no rule found for checking signatures from miles@gnu.org--gnu-2004

   Consider creating ~/.arch-params/signing/miles@gnu.org--gnu-2004.check
   or ~/.arch-params/signing/=default.check

   I mean, what's the content of the files? A GPG signature or something?

 - The revision library it's already 160MB.  What should I do when it
   grows too much? "tla uncacherev", perhaps?

Thanks,

                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Sat, 12 Jun 2004 09:11:30 -0400, Miles Bader <miles@gnu.org> wrote:

> I've updated things.

I'll check it as soon as bootstrapping's working again.

Thanks,


                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Jason Rumney]

Juanma Barranquero <lektu@mi.madritel.es> writes:

> From revision 1.1, nt/configure.bat has had:
>
>    if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile Makefile.unix
>
> In 1.5, Eli changed it to
>
>    if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile.in Makefile.unix
>
> Curiously, the log says: "Don't copy lisp/Makefile, it doesn't exist;
> copy lisp/Makefile.in instead."

I think that change was a mistake. The intention of that line seems
to me to be to make a backup of the makefile before overwriting it,
in case the user uses a dual-boot or networked drive for the source
tree and wants to recover the unix makefile without reconfiguring
after building the Windows version.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Sat, 12 Jun 2004 23:19:17 +0900, Jason Rumney <jasonr@gnu.org> wrote:

> I think that change was a mistake. The intention of that line seems
> to me to be to make a backup of the makefile before overwriting it,
> in case the user uses a dual-boot or networked drive for the source
> tree and wants to recover the unix makefile without reconfiguring
> after building the Windows version.

Perhaps it was failing when thre's no lisp/Makefile, and that's why Eli
changed it.  Anyway, it's been like that for almost three years and half,
so perhaps there aren't developers doing that kind of dual-boot or
shared working copy development.  I'd suggest just removing the line and
waiting.  If someone barks, we can fix it later.

                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Eli Zaretskii]

> Date: Sat, 12 Jun 2004 16:31:26 +0200
> From: Juanma Barranquero <lektu@mi.madritel.es>
> 
> Perhaps it was failing when thre's no lisp/Makefile, and that's why Eli
> changed it.

That almost certainly was the case: someone complained about that line
failing, and I made the change to avoid that.

I have no idea why the line was there in the first place.

Re: Checkout of Emacs CVS through firewall

[Eli Zaretskii]

> Date: Sat, 12 Jun 2004 14:55:00 +0200
> From: Juanma Barranquero <lektu@mi.madritel.es>
> 
> On Sat, 12 Jun 2004 00:44:46 -0400, Miles Bader <miles@gnu.org> wrote:
> 
> > Offhand it sounds like something that should be fixed in nt/configure.bat.
> 
> From revision 1.1, nt/configure.bat has had:
> 
>    if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile Makefile.unix
> 
> In 1.5, Eli changed it to
> 
>    if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile.in Makefile.unix
> 
> Curiously, the log says: "Don't copy lisp/Makefile, it doesn't exist;
> copy lisp/Makefile.in instead."
> 
> I'm going to ask Eli what's the purpose of this line and whether it cold
> be changed to really copy, instead of moving.

What is the problem with that line, anyway?  (I didn't follow this
thread closely enough, so if it was already described, please point me
at the appropriate message.)

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Sat, 12 Jun 2004 20:32:23 +0200, "Eli Zaretskii" <eliz@gnu.org> wrote:

> What is the problem with that line, anyway?  (I didn't follow this
> thread closely enough, so if it was already described, please point me
> at the appropriate message.)

Not a big problem: Arch complained that it knew about a file which
had disappeared (Makefile.in, not Makefile.unix).  But I'm wondering
whether the line is, in fact, useful at all.



                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Sun, Jun 13, 2004 at 12:10:33AM +0200, Juanma Barranquero wrote:
> > What is the problem with that line, anyway?  (I didn't follow this
> > thread closely enough, so if it was already described, please point me
> > at the appropriate message.)
> 
> Not a big problem: Arch complained that it knew about a file which
> had disappeared (Makefile.in, not Makefile.unix).  But I'm wondering
> whether the line is, in fact, useful at all.

Note that this reflects a general truism -- your makefiles probably shouldn't
be screwing with your source files, unless you actually intend to _change_
them, especially if you're using a source-control system.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Checkout of Emacs CVS through firewall

[Juanma Barranquero]

On Sat, 12 Jun 2004 18:54:16 -0400, Miles Bader <miles@gnu.org> wrote:

> Note that this reflects a general truism -- your makefiles probably shouldn't
> be screwing with your source files, unless you actually intend to _change_
> them, especially if you're using a source-control system.

Very true.

                                                           /L/e/k/t/u

Re: Checkout of Emacs CVS through firewall

[Stefan]

>> leim/quail/4Corner.el
>> leim/quail/ARRAY30.el
>> leim/quail/CCDOSPY.el
> [... etc ...]

> These are annoying; it would be nice if they were built using some sort
> of consistent naming convention, but I guess they could be enumerated
> as "to be ignored".

Yup.

~/tmp-0% cat ~/src/emacs/work/leim/quail/.arch-inventory
precious ^(CTLau-b5|CTLau|PY|ZIRANMA|quick-b5|quick-cns|tsang-b5|tsang-cns|4Corner|ARRAY30|CCDOSPY|ECDICT|ETZY|PY-b5|Punct-b5|Punct|QJ-b5|QJ|SW|TONEPY|ZOZY)\.el$

# arch-tag: b76ab876-6b85-11d8-a8bd-000a95e675a6
~/tmp-0% 


        Stefan

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

Stefan <monnier@iro.umontreal.ca> writes:
> ~/tmp-0% cat ~/src/emacs/work/leim/quail/.arch-inventory
> precious ^(CTLau-b5|CTLau|PY|ZIRANMA|quick-b5|quick-cns|tsang-b5|tsang-cns|4Corner|ARRAY30|CCDOSPY|ECDICT|ETZY|PY-b5|Punct-b5|Punct|QJ-b5|QJ|SW|TONEPY|ZOZY)\.el$

I ended up using this:

   precious ^([A-Z0-9].*|tsang-.*|quick-.*)\.el$

All the source files are lower case... :-O

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: Checkout of Emacs CVS through firewall

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: Tue, 29 Jun 2004 10:17:55 +0900
> 
> Stefan <monnier@iro.umontreal.ca> writes:
> > ~/tmp-0% cat ~/src/emacs/work/leim/quail/.arch-inventory
> > precious ^(CTLau-b5|CTLau|PY|ZIRANMA|quick-b5|quick-cns|tsang-b5|tsang-cns|4Corner|ARRAY30|CCDOSPY|ECDICT|ETZY|PY-b5|Punct-b5|Punct|QJ-b5|QJ|SW|TONEPY|ZOZY)\.el$
> 
> I ended up using this:
> 
>    precious ^([A-Z0-9].*|tsang-.*|quick-.*)\.el$

I hope this doesn't give trouble on case-insensitive file systems.

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

On Tue, Jun 29, 2004 at 07:06:14AM +0200, Eli Zaretskii wrote:
> >    precious ^([A-Z0-9].*|tsang-.*|quick-.*)\.el$
> 
> I hope this doesn't give trouble on case-insensitive file systems.

It shouldn't -- the matching is done by an application program, not the
filesystem.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Checkout of Emacs CVS through firewall

[Eli Zaretskii]

> Date: Tue, 29 Jun 2004 03:18:14 -0400
> From: Miles Bader <miles@gnu.org>
> 
> On Tue, Jun 29, 2004 at 07:06:14AM +0200, Eli Zaretskii wrote:
> > >    precious ^([A-Z0-9].*|tsang-.*|quick-.*)\.el$
> > 
> > I hope this doesn't give trouble on case-insensitive file systems.
> 
> It shouldn't -- the matching is done by an application program, not the
> filesystem.

Sorry, I don't follow: under a case-insensitive filesystem, you might
get array30.el instead of ARRAY30.el, in which case you're toast,
right?

Re: Checkout of Emacs CVS through firewall

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Tue, 29 Jun 2004 03:18:14 -0400
>> From: Miles Bader <miles@gnu.org>
>> 
>> On Tue, Jun 29, 2004 at 07:06:14AM +0200, Eli Zaretskii wrote:
>> > >    precious ^([A-Z0-9].*|tsang-.*|quick-.*)\.el$
>> > 
>> > I hope this doesn't give trouble on case-insensitive file systems.
>> 
>> It shouldn't -- the matching is done by an application program, not the
>> filesystem.
>
> Sorry, I don't follow: under a case-insensitive filesystem, you might
> get array30.el instead of ARRAY30.el, in which case you're toast,
> right?

But it should work on a case-preserving filesystem, which at least VFAT,
NTFS and HFS[+] are.

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: Checkout of Emacs CVS through firewall

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Wed, 30 Jun 2004 00:31:57 +0200
> 
> > Sorry, I don't follow: under a case-insensitive filesystem, you might
> > get array30.el instead of ARRAY30.el, in which case you're toast,
> > right?
> 
> But it should work on a case-preserving filesystem, which at least VFAT,
> NTFS and HFS[+] are.

I was thinking about a scenario where some tool renames a file to its
lower-case variant.  On a case-insensitive system, when Emacs tries to
open 4Corner.el, it will happily find 4corner.el, so this could go
unnoticed for a long time.

Re: Checkout of Emacs CVS through firewall

[Miles Bader]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> But it should work on a case-preserving filesystem, which at least VFAT,
>> NTFS and HFS[+] are.
>
> I was thinking about a scenario where some tool renames a file to its
> lower-case variant.  On a case-insensitive system, when Emacs tries to
> open 4Corner.el, it will happily find 4corner.el, so this could go
> unnoticed for a long time.

So don't use tools that screw up your filenames -- or if you must do so,
at least understand that it _will_ confuse any source-control system
you happen to be using.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Checkout of Emacs CVS through firewall

[Stefan]

>>> > >    precious ^([A-Z0-9].*|tsang-.*|quick-.*)\.el$
>>> > I hope this doesn't give trouble on case-insensitive file systems.
>>> It shouldn't -- the matching is done by an application program, not the
>>> filesystem.
>> Sorry, I don't follow: under a case-insensitive filesystem, you might
>> get array30.el instead of ARRAY30.el, in which case you're toast,
>> right?
> But it should work on a case-preserving filesystem, which at least VFAT,
> NTFS and HFS[+] are.

VMS doesn't preserve case.  But it doesn't run tla either.


        Stefan

Re: Checkout of Emacs CVS through firewall

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Reply-To: Miles Bader <miles@gnu.org>
> 
> So don't use tools that screw up your filenames

I don't.

I actually thought about your time being wasted by some bug report
that could boil down to something as obscure as this (I've seen
similar problems before), but I obviously don't need to worry about
that more than you do.