versioned file api audit
Robert Collins
robertc at robertcollins.net
Mon Mar 17 23:23:04 GMT 2008
On Mon, 2008-03-17 at 20:29 +1100, Martin Pool wrote:
> On 17/03/2008, Robert Collins <robertc at robertcollins.net> wrote:
> > so I just audited the public interface of versioned file. Heres what I
> > propose we keep/discuss/remove from it.
> >
> > get_parent_dict (because this is what bzrlib.graph wants; iter_parents
> > is
> > better on incremental work)
>
> I don't see any existing function called get_parent_dict.
get_parent_map - a typo.
> > iter_lines_added_or_present_in_versions
> > weave_merge
> >
> > apis to discuss:
> > plan_merge (perhaps keep this)
>
> This is closely related to weave_merge, and so probably should be
> kept. Maybe it should be a private method and called by rather than
> passed to weave_merge.
>
> You could say perhaps this will not vary with VF implementation, and
> the vf should instead just give annotation data to something else.
Thats what I'm mulling over :). It's neither hard or easy to keep it; I
haven't done a lot with the text merging stuff, most of my hacking has
been lower or higher in the stack. So moar input please!
> >
> > apis to remove:
> > has_version
>
> Why get rid of this?
Its slow (single version lookup), and it encourages look before you leap
programming; there are extremely few reasons to use this, and a trivial
replacement is
len(collection.get_parent_map([key])) == 1
for the places that really honestly need it. (I think there is one -
has_revision).
> > iter_parents
>
> is this not needed?
No - either it or get_parent_map is needed, not both.
> > clone_text
>
> "add a new text the same as an old one" is sometime useful; arguably
> not often enough to be a special case; anyhow probably better as an
> option to an add_method
Its already an option to add, clone_text is not used by bzrlib today.
> > create_empty
> > get_suffixes
> > get_text
> > get_texts
> > get_lines
>
> are you really going to have no method to get texts back out?
Bah! I was meaning to choose one :). Lets have two, because we have
substantial performance impact from line splitting/joining, and the
native implementation should be used directly when possible:
get_bytes(versions) -> iterator of (sha1, bytestrings)
get_lines(versions) -> iterator of (sha1, lines_list)
> > get_ancestry
> > get_ancestry_with_ghosts
>
> agree
>
> > get_graph
> > get_graph_with_ghosts
>
> why get rid of them? if we plan to have a per-vf graph, this seems
> like the way to expose it.
get_graph returns a dict. the graph is exposed via get_parent_map &
versions. (though I want to rename versions all_keys).
> > transaction_finished
>
> agree.
>
> That would be a nice cleanup!
Thanks :)
-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: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080318/3eae0a04/attachment-0001.pgp
More information about the bazaar
mailing list