Re: [Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest etc)

[David Allouche]

On Wed, Dec 03, 2003 at 12:38:17AM +0100, Pau Aliagas wrote:
> On Tue, 2 Dec 2003, Tom Lord wrote:
> >   And how about a per-library or per-library-part flag that says
> >   whether --sparse is the default, along with some other parameters:
> > 
> >     tla library-policy [--every <N> | --decay] \
> >                            [--greedy] \
> >                            [--sparse=yes|no] \
> >                            <library>  \
> >                            [<archive>|<fqcat>|<fqbranch>|...]
> > 
> >     tla library-lock [--unlock] <revision> [<library>]
> > 
> >         tla library-prune [<library> [<archive>|<fqcat>|...]]
> > 
> >   where library-prune attempts to reduce the number of 
> >   revisions in (optionally: some part of) a library following
> >   the rules:
> > 
> >         ~ keep all locked revisions
> >         ~ keep all revisions whose link count indicates that
> >           there are hardlinks from other library versions or
> >           from project trees
> >     ~ within those constraints, get as close as possible
> >           to (depending on the policy) every Nth revision
> >           or an exponential decay from most recent to 
> >           oldest

Most of this discussion is flying way over my head, but...

The "keep all revisions whose like count indicates that there are
hardlinks from other library versions or from project tree" heuristic
seems broken to me.

If I understand well, a revision is considered unlinked when all its
files have a link count of exactly 1 (one). Usually, this should never
ever happen. Every revision in the history is going have at least one
file which is identical in the previous revision (the README, COPYING,
bosskill man page, etc...). As long as this holds, you can prove by
recurrence that no revision is ever going to meet the "not linked"
condition.


> >   With those low-level mechanisms in place, we can imagine a 
> >   high-level convenience command.   Something like:
> > 
> >     tla project-mirror [params] <name> <project-spec>
> >   
> >   where the <project-spec> is a list of archives and/or
> >   fully qualified categories, branches, or versions and
> >   the params specify:
> > 
> >     ~ if and where to create local archive mirrors
> >         ~ if and where to add the archives, categories, etc.
> >           to particular libraries
> >         ~ what library caching policies (if any) to apply 
> >           to the archives, categories, etc.
> > 
> >   Perhaps then:
> > 
> >     tla sync-project <name>
> > 
> >   to issues all the necessary push-mirror commands and
> > 
> >     tla prune-project <name>
> > 
> >   to issue appropriate library-prune commands.
> 
> Mmmm... maybe these should be external scripts if they don't add anything 
> new. Just let's distribute a scripts directory with all these convenient 
> utils, but let's not complicate arch with thes aggregation commands. Isn't 
> that what itla is all about?

That is a bit off-topic, but I am concerned by the uncontrolled
proliferation of convenience commands which add no expressiveness to the
toolset. When you are considering the "language binding issue" you want
to know what is the set of core functionality you should bind with
and what it would be reasonable to reimplement yourself (because it is
mere convenience).

For one thing, mixing convenience commands (archive-setup) with
low-level core commands (make-category/branch/version) makes it harder
for the user to figure out what is the command he needs to use by
skimming through "tla help" output.

Also, there is a general issue of layering and helping people grok arch
in fullness. If core commands were separated from convenience commands,
I guess it would be easier for users to get a clear view of what is the
"basic language" (core) and what tools there are for common scenarios
(convenience).

Mhh... when I reread myself I find my explanation a bit confused. So let
me restate:

  -- There should be a clear separation between core and convenience
     commands.

Because:

  -- tla supposedly is self-documentating, and chaotic proliferation of
     commands defeats that purpose.

-- 
                                                            -- ddaa