file ancestors

[Martin Pool]

On 22 Nov 2005, Johan Rydberg <jrydberg at gnu.org> wrote:
> Hi folks,
> 
> The attached patch adds a "file_graph" method to the Branch class
> which returns two maps, ancestors and descendants, for modifications
> to the file.  The idea is that it can be used to implement per-file
> revision logs (think "bzr log FILE").  Aaron suggested the return data
> format, to let the function line up with the revision_graph function.

Lining up with that is good but perhaps it'd be better to return some
kind of graph object that allows looking up ancestors and descendents,
rather than the bare maps.

> To give it a spin I tried to hook it up in _show_log, but without any
> great success.  The problem is two fold:
> 
>  1.  It is not uncommon that revisions that modify the file is not in
>      the linear branch history (i.e., the revisions has been merged).
>      and "bzr log" only shows revisions that have a revision number.
> 
>  2.  file_graph does not (of course) identify changes to the
>      name space (i.e., renames, deletes and moves)
> 
> The first problem can most likely be solved by building a graph of the
> whole branch, and use that to find out which revision merged the
> modifying revision.  Or does anyone else know of any simple solution?

Another approach, which might be simpler, would be to compare the
mainline revision-history to the file weave (or a file graph object),
and look for revisions in which there are new entries.  Leaving aside
renames for the moment, that would be as easy as just looking for
revision-ids which are in the weave's table of contents.

That would also tell you of revisions in which the file was merged but
unchanged from the previous mainline revision, but that's probably a
useful behaviour.

> A workaround could be that "bzr log" could show revisions without
> revision numbers (merged revisions) -- but when the revision was
> merged is most likely as important information as when the actual
> change was made.

I think it would be nice if the indented-form log did show where the
changes to a particular file originated.

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

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

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051123/80c586b3/attachment.pgp