[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [Gnu-arch-users] How to support arch on systems with a small PAT
From: |
Ron Parker |
Subject: |
Re: Re: [Gnu-arch-users] How to support arch on systems with a small PATH_MAX [WAS: arch o n windows?] |
Date: |
Thu, 15 Jul 2004 13:42:41 -0500 |
On Thu, 15 Jul 2004 06:25:38 +0200, address@hidden <address@hidden> wrote:
> pathnames like
>
> category/category--branch/category--branch--version/
> and
> category/branch/version/
>
> can friendly coexist without breaking upward compatibility.
> all which needs to be done:
>
> 1) tla needs to check if the directory names beyond category/ contain a
> double dash '--' then it's a legacy long pathname, else it's a short
> pathname.
>
> 2) tla needs some new 'short-path' flag in '{arch}' and '=meta-info'
> (and correspondending --short-path options) which it uses to determine
> if new dirnames there will be created with long (legacy/compatible) or
> short pathnames.
If I can find the time, I am willing to work on this. However, since
I didn't see the IRC discussion, I need a little clarification. Are #1
and #2 partially redundant?
I mean, I can see the need for #2 because init-tree could add a
=short-path flag in {arch} on POSIX-minimal systems before the
category/category--branch directory is created. Optionally this could
be done on longer PATH_MAX systems with a flag to init-tree. The same
applies to the make-archive command.
However, where does the implicitness of #1 come into play? Is this for
data in the ,,commit..., {revlib} and similar directory structures?
If so, I think I like it. But I also need to know if #1 is meant to
imply that Tom expressed a desire or willingness to shift to c/v/b
universally in the future or is that inferring too much?