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

[David Allouche]

On Wed, Dec 03, 2003 at 05:41:00PM +0000, Mark Thomas wrote:
> On Wed, 3 Dec 2003, Tom Lord wrote:
> 
> > 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.
> 
> I think this is the better approach.  There's always going to be *one*
> file *somewhere* in the tree that hasn't been updated since time
> immemorial, and that file would keep all the old revisions in the library
> (unless you start ranking a revision's importance by the _number_ of files
> in the tree that are linked into from somewhere else).

We can add something to this heuristic to make handle that case
correctly.

At the moment we have

  f a given file in a given revision in the library.

  n(f) the link count of file f.

  l(f) the count of links which are internal to the revision library.
  Invariant: l(f) <= n(f)

  P(r) the test for "we can remove revision r from the library".
  Currently: P(r) <=> for all files f in r l(f)=n(f)

We can change it slightly:

   C(r,f) <=> revision r "created" file f
   That means f is either new, patched or otherwise modified in r.

   P(r) <=> for all files f in r where C(r,f), l(f)=n(f)

That means, that a working tree will only hold in the library the oldest
revisions which contains any of its files. Or did I got it wrong once
more?

So all the never-changing files would just hold the original revision.
All in all, I think this heuristic is quite smart when accesses to the
revision library are random. I believe this would result in a sensible
sparse library. But this might also let the library grow too big when
working with the full history of huge trees.

However, accesses to the library are _not_ random. Essentially
everything happens on recent versions. Also, all this link counting is
either expensive to do, or complicated to code. Finally, this is maybe
_too smart_ and not predictible enough.

Some simple "keep the library below N megabytes, removing least recently
used (I guess that is what LRU stands for) revisions first" heuristic
may just be more reasonable and more effective for real world use.

Oh, by the way, what about getting revisions by reverse patching? ;-)


> >[convenience commands vs. core commands]
> >
> > 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.
> 
> Wasn't the plan for all the core commands to be those that directly map to
> function calls in libarch, making a core-command-only version of tla a
> trivial command-line option parser?  (or has the libarch plan been shelved
> while I wasn't looking?)
> 
> I for one am a very strong proponent of there being exactly one command
> that I use for my day to day work (whether that is tla or itla or
> whatever, I don't care, but I don't want to have to remember which command
> contains whichever function I want to use).

That is indeed the obvious solution.

But that would make scripts more complicate to write. If we call tlac
(tla core) the front-end for core commands and tla the user front-end
(whose subcommand set may overlap with tlac), subcommands like
make-category/branch/version would be removed from tla (but kept in
tlac) when archive-setup is introduced. So script writers would have to
give precedence to tlac over tla so their code would not break when a
high-level command is introduced.

But is that really a problem?

-- 
                                                            -- ddaa