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

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

Re: [Gnu-arch-users] Re: Making microbranches popular


From: David Allouche
Subject: Re: [Gnu-arch-users] Re: Making microbranches popular
Date: Wed, 28 Jan 2004 14:06:41 +0100
User-agent: Mutt/1.5.5.1+cvs20040105i

On Tue, Jan 27, 2004 at 10:03:10AM -0500, Mirian Crzig Lennox wrote:
> (Incidentally, I see that there is now a "grab" subcommand in tla-1.1,
> though with different semantics than what you proposed and no
> corresponding "announce".)
> 
> > > From: Tom Lord <address@hidden>
> > > Date: Wed, 23 Jul 2003 08:13:32 -0700 (PDT)
> > > Subject: [arch-users] grab and announce -- yes.  (Re: [...] Version 
> > > sorting proposal)
> > >
> > > It seems to me that the root propblem people would like to solve is to
> > > take an arbitrary name from a release or from a project "branch" (in
> > > the expansive, non-specific arch sense), and have arch use that
> > > arbitrary name to access the sources.
> > >
> > > For example, people would like to be able to somehow `tla get'
> > > something called "linux-2.16ac" and wind up with a project tree
> > > of those sources.

It seems that nobody has noticed that the message I wrote which all
started this flamy subthread proposed a way to implement just that one
feature.

Some discussions on #arch strongly suggest there is some massive
confusion and misunderstanding going on about the "archive-metada
category" proposal. I plan to clear that up soon, but I would like to
stay somewhat on topic w.r.t. to that thread.

> > > Let's call those arbitrary names (like "linux-2.16ac") "external
> > > names".
> > >
> > > There are some obstacles:  
> > >
> > > 1) In general, external names do not map on to the arch namespace
> > >    without mangling.  We might say:
> > >
> > >   linux--ac--2.16
> > >
> > >    but some people find that objectionable or confusing.

Okay, so we can use "convenience aliases" which are aliases to any arch
package name, either version, branch, or revision. For example
"linux-2.16ac" could be alias for "linux--ac--2.16".

At argument parsing time, the CLI would check package parameters against
existing convenience names and subsitute them if and only if there is a
full-word match.

> > > 2) In general, what external names name, in arch terms, may vary.  Is
> > >    linux-2.16ac the name of a specific revision?  Is it the a name for
> > >    an arch version?  Is it the name for a revision or version of a
> > >    top-level directory plus a multi-project configuration?   There's
> > >    no one answer.

Any of those. 

Maybe the convenience alias names could be restricted to not contain
"--", so it would be possible to relax the "full word match" rule into a
"match between start of word and --".

That would allow using linux-2.16--patch-42 to refer to a specific
patch, because linux-2.16ac is alias for a version.


> > > The idea has expanded slightly, to having a pair of commands.
> > >
> > >
> > >   % tla announce EXTERNAL-NAME [..???..]
> > >
> > >         Publish the mapping from some external name to the
> > >         corresponding arch entities.
> > >
> > >
> > >   % tla grab EXTERNAL-NAME [ARCHIVE-OR-LOCATION]
> > >
> > >         Retrieve he arch entities described by EXTERNAL-NAME.
[snip]
> > >   1) What are the parameters to tla announce?
> > >
> > >            In other words, how can external names be defined?
> > >
> > >
> > >   2) What does grab actually do?
> > >
> > >            What does the definition of an extern name _mean_?

I am not in the known of this whole issue, it seems to address a larger
issue that what I am discussing right now.

What I envision is:

  aba alias [name] [package]
  
An alias would mean nothing in particular. To avoid confusion, the
output of commands like abrowse would display the actual arch names.
Alias are only convenience for input.

Note that I says "aba" and not "tla" because this convenience feature
should be protoped on aba first and later get in tla if it is deemed
useful. There is no need to alter the core implementation to support it.

> > >   3) Other commands?
> > >
> > >      Do other commands use external names?   New commands? 
> > >            If so, how?  Perhaps, for example, external names can 
> > >            be used as part of a higher-level interface to configs.

All commands which expect package parameters should be able handle
aliases. The config support woud probably need a bit more hacking so
aliases could also be used in config files.

> > >         4) Implementation?
> > >
> > >      On #irc, we've talked about implementing this as new 
> > >            "stuff" in =meta-info in archives.   I'm having second
> > >            thoughts about that:   perhaps external names should
> > >            be automatically managed, specially-named versions.
> > >
> > >            XX-Externs--linux78-2x2e16ac--1.0
> > >
> > >            where the the revisions in that version contain a single
> > >            file (the definition of the name) and each log message 
> > >            contains a copy of the latest definition.

The alias mapping would be stored in the log file of the last revision
in archive-metadata--alias--1.

Actually, I see no need to store a copy of that information inside the
revision, since the patchlog is already part of the revision.

-- 
                                                            -- ddaa




reply via email to

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