tree transform is malformed ??

[Aaron Bentley]

Robert Collins wrote:
> On Mon, 2006-05-01 at 08:02 -0400, Aaron Bentley wrote:
>>One way to do what you want would be to write a conflict resolver that 
>>resolved creation of an existing directory by versioning the existing 
>>directory, instead of by renaming the existing directory.
>>
>>And what about creating existing files, then?  I think it gets very DWIM 
>>very fast.
> 
> 
> I think this is where the prior discussion failed.
> 
> I think it is a requirement for supporting nested trees that the example
> I provided above works. 

I don't see anything about nested trees that requires it to be possible 
to do checkouts in non-empty directories at all.

> As for files, I dont care. Note that there is a
> separate specification for merges that says when two directories have
> the same name, and neither id is present elsewhere, they should have
> their contents combined rather than one become foo.moved.

If the directories merely happen to have a common name (e.g. "foo", 
"test", etc), this is bad, as it will put files together that should not 
be together.  It's especially bad if the directories have files with 
common names (e.g. __init__.py) which are not the same logical file.

On the other hand, if the directories really are logically one 
directory, and what happens to the files?  Since we don't have a base 
revision, we can't do a three-way merge.  Do two-way merge?  Conflicts 
everywhere the two files disagree?  I don't think that's very helpful.

So spec or not, I think there's room to question whether this is the 
right idea.

But I'm not in this to be obstructionist.  If you want to write a new 
conflict resolver for build_tree, you can.  That's a nice thing about 
having separate ops for revert, merge and build_tree-- we can customize 
them a lot more freely.

Aaron