Re: [Gnu-arch-users] Amendment to Path Problems

[Tom Lord]

    > From: Michael Grubb <address@hidden>

    > I'm an idiot.

Bummer :-)

    > This is no command length issue(well it may be a combination 
    > of the two), it is a depth problem.  Windows doesn't seem to support more 
    > than 23-24 directories deep.

Ouch.   You mean that there is a file-system limit that says you can
not create, by any means, a directory more than 24 components away
from "/"?

The maximum depth of arch control files in a single project tree is 7
(unless I'm miscounting) relative to the project tree root.

Therefore, the maximum depth of a control file in a pristine tree is
something like 15.

Does `link(2)' work on Cygwin?  The maximum depth in a revision
library is something like 14, relative to the library root.

Archives are relatively shallow.

So, arch trees are not themselves likely to exceed a depth limit of
23-24.   If you store one around 10 directories deep, though, you'll
run into such a limit.

(A file-system depth limit of around 24 components?  Really!?!
Sheesh.)


    > This is a much less trivial problem to solve, but for arch to
    > gain widespread popularity as CVS has, this problem must be
    > addressed.  For my limited skills with C I will be happy to do
    > what I can, I just need a nudge in the proper direction.  The
    > bigger question this raises is how does this affect overall
    > `arch'itecture?

    > Thanks again,
    > Sorry for being a DA!

I'm not sure you were wrong in the first place about the 280 character
limit.  The depth limit of 23-24 components is not something I've
heard of.   Hopefully someone will pipe in with a definitive account.

Since arch trees don't themselves exceed such a depth limit, a decent
work-around initially is just to say "don't store an arch tree too
deep in the file system.

We can cut the depth of project trees almost in half by storing
pristine trees more shallowly -- that's an easy change.

We can shave about 4 components off of revision library paths by
storing those more shallowly (optionally, at least -- so as not to
perturb existing browsers and scripts).   That's another easy change.

Perhaps that alone would be enough.   That leaves the depth-7
patch-log entries.   7 isn't all that deep -- regular 'ol source trees
do that sort of thing.

It would not be an easy change to change the depth of patch-log
entries but let's assume that it is necessary.

Once again: `vu' to the rescue -- but it's _slightly_ trickier this
time.   We can add a namespace handler for files matching (roughly)

        ^(.*/)?\{arch\}/[[:alpha:]]([[:alnum:]])*(/.*)?

and abbreviate their paths (and re-expand them in readdir).

That's tedious but pretty easy.

The slightly tricky bit is that the same change must then be made to
`tar' so that, in tar files (for imports and changesets) the full
paths, not the abbreviated ones, are still used.

If GNU tar uses only man(2) functions to open files -- that's an
_easy_ change.  Grep for system calls (`open', `read', `write', etc)
and turn them into `vu_*' calls.  The interface for most is almost the
same except that `errno' is replaced by an initial `int *' output
parameter.   As I recall, the directory-reading functions are slightly
different.

(diff, patch, and diff3 are an issue too:  either they can be modified
to use `vu' internally, or gross code can be added to the fork/exec
sequences for them.)

It's a bit harder if the GNU tools use stdio functions such as
`fopen'.   That might take some more radical surgery.

-t