[MERGE] Remove interdependency between WorkingTree and RevisionTree

[Jelmer Vernooij]

On Mon, Jul 17, 2006 at 11:20:42AM -0400, Aaron Bentley wrote:
> John Arbash Meinel wrote:
> > Aaron Bentley wrote:
> >>>I'm not against having an SVNRevisionTree, I'd just like to know why, so
> >>>we can determine whether RevisionTree should be adjusted to make it more
> >>>generic.
> > Because RevisionTree expects everything to be in a Weave (it uses
> > get_*_weave() directly from the Repository).
> Well, actually, it uses a VersionedFileStore.  And VersionedFileStore
> provides get_lines(self, file_id, rev_id, transaction), which looks like
> the ideal way to implement RevisionTree.get_lines.  Though I see it's
> been deprecated.
That isn't an ideal interface for me either. At the moment, I can
create a RevisionTree using a single roundtrip (I just fetch 
one particular Subversion subtree, and that includes properties).
Implementing a VersionedFileStore would be a less optimal solution as
it'd require complicated code to deal with different versions of files, and be
incomplete as I can't annotate lines cheaply. 

Subversion branches don't use VersionedFile or VersionedFileStore at all at 
the moment, and I don't see why they should here. Generating a RevisionTree
from a SVN checkout is very straightforward whereas providing a
VersionedFileStore based on multiple checkouts would be complicating
matters.

> > And creating a VersionedFile from SVN is expensive. Versus what
> > RevisionTree actually needs.
> But by that logic, you would expect to be able to implement a
> VersionedFile that supplied what RevisionTree actually needs very
> cheaply.  Or change RevisionTree to use VersionedFileStore.get_lines(),
> if that's a better abstraction, and undeprecate it.
VersionedFile is problematic for Subversion as it's relatively cheap
to fetch the whole tree for a particular revision rather than a single
files' contents.

Cheers,

Jelmer