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

[Tom Lord]

    > From: David Allouche <address@hidden>

    > > >   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...

Doesn't seem like it.

    > 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.

Right, you're only off by saying "1".   But also, I think the link
count idea is more complicated than it needs to be.   So here's an
explanation of what I was thinking but then also a better idea:

Suppose I have some set of revisions in the library.   There's some
file, say, COPYING, that is shared among all those revisions.   So, 
if there's 10 revisions, and the file has 10 links to it, then I know
that there are no project-trees linked to that file.

On the other hand, if there are 11 links to COPYING, but only 10 of
them come from the library, then the user has some project tree
somewhere that is linked here.

If all of the files in a given revision have only links internal to
the library, then its a good bet you don't need that revision.

That, said, though -- it's probably a needlessly complicated
heuristic.  All that "counting up links" would be fairly expensive and
it isn't a precise way to measure the "demand" for a given revision.

So, perhaps it would be better to ignore the link counts and, instead,
whenever a library revision is used for some purpose, touch a
timestamp file in the library -- then (within the constraint of
--every N or whatever policy is in effect) delete revisions in LRU
order.



    > > >   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.

I agree with all of that.    

There are parts of the proposed library hacks that _are_ core
functionality, and parts that are clearly "convenience" commands and
ideally belong in itla.

I didn't try to make a clear separateion when I wrote up the spec
because it would be hard to get right a priori -- it's more something
to work out during implementation.

-t