gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Proposal: tla tree-description


From: Miles Bader
Subject: [Gnu-arch-users] Re: Proposal: tla tree-description
Date: 03 Mar 2004 10:36:11 +0900

Rob Kaper <address@hidden> writes:
> I'd like to know if anyone else is interested in an extension to arch to set
> a description for a project:
> 
> tla tree-description [options] [description]
> 
> to list or set a short description for a project tree.

What do you mean `for a project tree' -- that it should be stuck into
{arch}/=description or something?

That would be easy to implement, and be nicely version controlled, but
seems to have some problems:

 * It's inconvenient for typical archive browsers: to find the
   description for a version, it would have to track down the
   description file in the history, apply diffs, etc. (essentially,
   check out the file).

 * It's probably not exactly what users expect/want: they probably want
   a description for each _category_ and _branch_, but if the
   description file exists in the project tree -- i.e., in a specific
   version -- it's not clear where to get this info from (for a branch,
   which version?  The latest?  For a category, which branch?).

Did you really intend something that gets stuck into the _archive_
director(y,ies)?  If so, that might solve the above problems, but
presents other issues, e.g., the description files wouldn't be version
controlled, and might pose problems for mirroring (arch's mirroring
mechanism for the most part doesn't attempt to propagate changes to
already-mirrored files, just new ones).

I think this issue has been discussed a fair bit in the past, so a
troll of the mailing-list archives might be enlightening.

I think one of the better ideas was a special `meta-info'
category/branch, which followed the normal archive rules, but contained
meta-info that might be interesting to archive browsers.  I didn't like
some of the suggestions that were being made about possible uses, but
for something like this, it might be exactly the right thing.

Thanks,

-Miles
-- 
I'd rather be consing.




reply via email to

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