[MERGE/RFC] MemoryTree and a TreeBuilder helper

[John Arbash Meinel]

Robert Collins wrote:
> On Thu, 2006-09-07 at 17:04 -0500, John Arbash Meinel wrote:
>> Robert Collins wrote:
>>> On Thu, 2006-09-07 at 15:32 -0500, John Arbash Meinel wrote:
>>>> ...
>>>>
>>>> v- Because we aren't testing it as an API, shouldn't it be private
>>>> _MutableTree, which is just an implementation detail?
>>> Its a base class for WorkingTree, I think its distateful to have a base
>>> class of a public facility be private. Also, I can add interface tests
>>> for it if you feel thats better - I was on the fence : on the one side
>>> I'm testing the specific behaviours on wt and on memorytree which could
>>> be consolidated. On the other hand, theres still quite some setup to
>>> make interface tests.
>> I agree it is distasteful to have a public object use a private one as
>> the base.
>>
>> My concern was just that you now have an API which isn't directly
>> tested, which has to be preserved across versions because of our strict
>> deprecation rules. And since it isn't directly tested, it is very easy
>> to mess up, and violate an old invariant that you didn't know was there.
>>
>> (The pypy guys have an interesting "solution", in that their api is only
>> defined by the test suite.
> 
> So we have three choices:
>  * Take the current patch
>  * Make MutableTree private
>  * Add interface tests.
> 
> I think the current patch is fine - because MutableTree is not a
> concrete implementation - its not directly usable, only WorkingTree and
> MemoryTree, or external subclasses are directly usable.
> 
> If the current patch isn't fine, my preference is adding interface tests
> for MutableTree, which would exercise WorkingTreeFormat* and MemoryTree.
> ..

I'm okay with the current patch. I don't really want you spending a lot
of time making these changes, rather than working on other things.
Though I do think adding an interface test for MemoryTree is the
"correct" way to do it.

>> file=>symlink is a little bit more straightforward. But it seems like
>> making a file change to a directory automatically because the path is
>> the same is more likely to be wrong than it is to be right.
> 
> Possibly we want a '--force-kind-change' option to the UI ?
> 
> Rob

I haven't really thought through what the correct thing is. I'm 50% okay
with Aaron's changes, because I do think we need to support changes in
conversions from other projects.

I could also see something like 'bzr update-kind path/to/foo'.
Though now your command line api starts having too many knobs.

However, I was able to setup an svn repository, and change a filename to
a directory. And 'svn status' gives:
~      f

Where ~ is defined as
'~' versioned item obstructed by some item of a different kind

So they don't allow it either.

Also, if you change a symlink into a file you get:
% svn status

!      .
~      b
~      f

(b was a symlink, but is now a file)

And
% svn commit -m 'foo'
svn: Commit failed (details follow):
svn: Entry '/home/jameinel/dev/,tmp/foo/b' has unexpectedly changed
special status

And at this point, I can't see any way to get svn to start responding
again. "svn rm" complains that there is some other object blocking me
from doing what I want. And 'svn add' claims that the path is already
versioned.

So I *really* don't think we want to follow their model. :)

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060907/2240c67c/attachment.pgp