[MERGE/RFC] MemoryTree and a TreeBuilder helper

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> 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.

Another case: they may have resolved a contents conflict in favor of a
directory.

For branch A, say there is a regular file, 'foo'.
Branch A is branched, creating branch B.
In branch B, 'foo' is changed into a directory, and committed.
In branch A, the contents of 'foo' are changed, and committed.
B merges A, producing a conflict, with foo.OTHER as a versioned regular
file, foo.THIS as an unversioned directory, and foo.BASE as an
unversioned regular file.  (There is no foo, because this is not a text
conflict.)
The user does 'bzr mv foo.OTHER foo', 'mv foo.THIS foo', 'bzr resolve
foo', 'bzr commit'.
Should they have to provide more confirmation that they want to change
the type of foo?

> file=>symlink is a little bit more straightforward. 

Also, directory <-> symlink seems reasonable.

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

I guess the most common example of this would be turning a Python module
into a package.  Rare, and somewhat questionable, since __init__.py is
likely more akin to the original module.

Currently, bzr
1. usually does not recognize when a kind change has taken place
2. cannot cope with certain kind changes due to bugs
3. takes no stance on whether or when kind changes should be permitted.

I would like to focus on the first two, and leave 3 for later, turning
it into "kind changes are always permitted" by default.  My reasoning is
that accidental kind changes are very rare, and so not a high priority,
both in implementation effort, and in UI space.  After all, we don't
want to end up with a gazillion different options to commit.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAKfN0F+nu1YWqI0RAt/kAJsHeNS9IHfNvvziDkDVMaSVF2JfcQCfauj5
aCrC2IA/zX9iN6CSRNjBJ+A=
=Mmkr
-----END PGP SIGNATURE-----