[MERGE] Let find_previous_heads take a repository.

[Robert Collins]

On Tue, 2006-06-13 at 01:28 +0200, Johan Rydberg wrote:
> InventoryEntry.find_previous_heads currently takes a store plus a
> transaction, and optionally a VersionedFile.  This exposes the
> underlying format to the inventory and commit functionality.  
> 
> This patch let find_previous_heads take a Repository object instead,
> and add a "get_file_ancestry" method to Repository.

I agree we need to reorganise this - I think this approach is not quite
right...

but perhaps a variation on it is a cleanup, even if not obviously better
it would be no worse.


> plain text document attachment
> (2006-06-13.bzr.find_previous_heads.txt)
> # Bazaar revision bundle v0.7
> #
> # message:
> #   Let find_previous_heads take a Repository.
> # committer: Johan Rydberg <jrydberg at gnu.org>
> # date: Tue 2006-06-13 01:23:29.792676926 +0200
> 
> === modified file bzrlib/bzrdir.py
> --- bzrlib/bzrdir.py
> +++ bzrlib/bzrdir.py
> @@ -1600,6 +1600,15 @@
>          The file needs to be added into the weave if it is a merge
>          of >=2 parents or if it's changed from its parent.
>          """
> +        class AncestryProvider(object):
> +            """Implement Repositorys ancestry file queries."""
> +
> +            def __init__(self, w):
> +                self._w = w
> +
> +            def get_file_ancestry(self, file_id, revision_ids):
> +                return self._w.get_ancestry(revision_ids)
> +
>          if ie.kind == 'root_directory':
>              return
>          file_id = ie.file_id


This is a little ugly: nested classes are probably not a good idea,
unless there is a clear need for them. In this case I dont think there
is a need for it... but lets step up a level...

And look at what is needed here:
we want the inventory entries 'last-modified' revision to change when
*any* of the following change:
content (text or symlink target)
name
parent id
ancestry (i.e. a merge from two branches that have ended up with the
same value in all other respects, independently).

This is what the find_previous_heads calculation is used to aid. The
*actual* storage of the ancestry is then less important: we want the per
file graph for log though, so having the graph matters.

In the abstract sense, the key calculation is neither a per-file
ancestry list, nor a per-file graph, but rather 'find the unique heads
from this set of parents', and return the 'parents list filtered to just
the unique heads, preserving order'.

A repository with cheap access to the entire file graph, might pull in
the graph and do set differences, a repository with more expensive graph
access might do a search from each head in parallel, thus not needing
the full graph.

So I propose an api of 'find_file_heads(file_id, heads_list)' on
Repository.

- This may be a little tricky to move around right now because of the
data-correction heuristic in there from the slight-mishap with the exec
bit waywayway back. -

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060613/b09b3d85/attachment.pgp