[MERGE/RFC] MemoryTree and a TreeBuilder helper

[John Arbash Meinel]

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.

...

> This API still cares about the file kind, its just allowing explicit
> overriding. Aarons patch to allow kind changing is related to this
> discussion. The most important thing IMO though, is to remember that the
> wt inventory is just the map - the disk is the territory, and we need to
> consider the inventory as being just a cache of what we last
> observed/what we've been told it should be.

I was just commenting about the comment. Not about your actual changes.

As far as the discussion, I actually think there should be some explicit
action to cause a entry to change kind. Because the user actually did
*something*. Whether they deleted a file and created a directory, or
moved the file out of the way, created a directory, and renamed the file
foo/__init__.py.

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. I actually cribbed this segment from a fix in the hpss branch,
> which I'd rather not conflict against - and its coming in with full
> tests.

Okay.

> Is that +1 ?
> 
> -Rob

Sure. +1.
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/ab10a0d0/attachment.pgp