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

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

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


From: David Allouche
Subject: Re: [Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest etc)
Date: Fri, 5 Dec 2003 13:45:59 +0100
User-agent: Mutt/1.5.4i

On Fri, Dec 05, 2003 at 01:24:25PM +0100, David Allouche wrote:
> On Thu, Dec 04, 2003 at 11:54:37AM +0100, David Allouche wrote:
> > On Thu, Dec 04, 2003 at 07:07:15AM +1100, Robert Collins wrote:
> > > there is a trivial heuristic:
> > > if any file in a revision's sources in a library has a link count of 1,
> > > then that revision hasn't been checked out. (modulo the slow rot that
> > > occurs from update and replay breaking links).
> > 
> > Unless of course the next revision is only renames, has zero change
> > (e.g. a version-0 revision) or is a continuation (i.e. a base-0). But
> > this might be considered a negligible space overhead.
> 
> Rah... said something wrong again...

Mh... actually not that wrong... even with the algorithm I gave, you
must have a special case for "entirely linked" revision (zero changes or
only renames). You must count the number L of successive revision
matching that pattern, then the parent (of count P=0 or 1) and children
(of count C) of that subtree must be tested for one file whose link
count is exactly L+C+P. Which must be updated as we delete revisions, of
course.

The heuristic is simple, but the algorithm needed to use it effectively
is not...

-- 
                                                            -- ddaa




reply via email to

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