versioned file api audit

[Martin Pool]

On 18/03/2008, Robert Collins <robertc at robertcollins.net> wrote:
>  > 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!

Then I would say, keep it for now, you will have a big enough patch
already, and it is not particularly coupled to anything else,
cluttering the api, or encouraging bad performance.

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

I would leave it and add a note to the docstring that it should not be used.

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

So that would be

  iter([(sha1, [bytes, ...]), ...])

?

  or iter([(sha1, iter([bytes, ...])), ...])

Since we currently use get_bytes(version) to get just one I suggest
you call it get_bytes_multi() or something.


-- 
Martin <http://launchpad.net/~mbp/>