file ancestors

[Johan Rydberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool <mbp at sourcefrog.net> writes:

>> Regarding building full branch graphs:
>> 
>> Right now revision_graph reads _every_ revision to get parent
>> information.  This is quite expensive, esp with a remote revision
>> store.  Maybe this information could be cached in a "revision-graph"
>> file in ".bzr" directory.  The format could be simple:
>> 
>>    REVISION-ID:PARENT[,PARENT[,...]]
>> 
>> If there is no entry for a revision in the file, it should be treated
>> as a ghost revision.  
>
> The inventory weave's graph will give you this, except that it does not
> mention ghosts.

Yes.  I've also added a "branch_graph" method to Branch that returns a
similar graph to revision_graph with the exception of that it does not
include ghosts.

Regarding having a special Graph-object; I think it is a good idea.  I
will talk to Aaron about it.

Anyway, with traversing the branch graph to find mergers I have been
able to get time for a "bzr log branch.py" down to ~22 seconds on my
old crappy P3 800Mhz.  Of that ~15 seconds is generating the branch
graph -- if we can get that number to start approaching zero, things
would be quite usable.

> We might be better off storing revisions within a single containing
> file, to reduce the number of roundtrips for remote branches.  This
> would do poorly with weaves but rather better with knits, because the
> revisions could be stored without delta-compression from one to the
> next.

I have thought about that as well.  But even those files may get
rather large.  

My opinion is that we need to speed up common operations such as "bzr
log FILE".  If that is possible without introducing a new "data
structure"/file/cache, great.  If not, I don't think we should be
afraid of having persistent caches.  As a fact, we already do:
revision-history.

>> I have yet to find a solution to the second problem listen above.  All
>> suggestions are welcome.  Right now every inventory is examined, which
>> is far from optimal.
>
> It's been suggested that renames/etc should also insert revisions into
> the file weave.  I think that would be quite reasonable.  One might then
> also want to record the path that the file had in a particular revision
> - this would be redundant with the inventory but probably useful.  We'd
> also want to record revisions in which the file was deleted.  With
> these, I think it would be possible to report the log for a file without
> needing to read and compare any inventories, which would be nice.

I thought about that as well, but I imagined for some reason that you
and/or Aaron would oppose it :)

~j
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFDhBYL3CqIy3K3X2ERAorJAJ9rf/Jz4QNEHpZmt7Eq1iVHwGnMrACfWQg8
C7gN7zZLs+KJk5PxtCi4Txs=
=654X
-----END PGP SIGNATURE-----