[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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]