Intent of TestCommitMerge.test_merge_new_file?

[Aaron Bentley]

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

Martin Pool wrote:
>>I think this is a clearer way of doing it than a command that says
>>"check out or branch this branch into this other branch, making its root
>>such-and-such subdirectory":
> 
> 
> Yes, I think you're right that it's cleaner.  But then why do you need
> two arguments?  Isn't it enough just to give the name of the directory
> which is going to be grafted?

Yes, I think the second argument could be optional.  You might use it in
scripts to ensure you get a failure if you try to graft a tree into
another tree that does not immediately contain it.  For example, "bzr
graft foo/bar/baz foo" would fail if foo/bar was a versioned tree nested
in foo, but "bzr graft foo/bar/baz" would simply graft "foo/bar/baz"
into "foo/bar".

>>The root directory can only have one id.  So if root ids differ between
>>branches, and you try to combine the root directory contents of those
>>branches, you'll be effectively deleting one root, and moving its files
>>into the other root.  This will come back to bite you when you do a
>>merge that adds new files to the deleted root.
> 
> 
> This may require some more consideration; merging two previously
> unrelated trees is a reasonable thing to do.  Perhaps it can be handled
> under the aegis of a regular merge that conflicts because the
> destination directory is deleted?  Perhaps it requires remembering what
> file ids or versions have already been merged in -- file-id joining, etc.

The best way to handle it that I can think of is file id aliasing.  We
could also special case the root directory so that if the OTHER root
directory is not present in THIS, the THIS root directory is used as the
parent of those files.

>>~  So typical use will be 'bzr graft ../somelibrary
>>| ./library'.
>>|
>>| We should test that revert correctly undoes the graft as I imagine
>>| people will fairly often change their mind or decide to graft it
>>| somewhere else.
>>
>>Interesting.  Given that step 4 of graft is "remove the control
>>directory of bar", that may be a problem.
> 
> 
> Well, I won't absolutely insist on revert working, but there does seem
> some risk here that people will lose some of their history.

Well, anything's possible if we want it badly enough, though I do like
Robert's suggestion of using the inverse operation ("bzr split?") in
that situation.

At the very least, the .bzr directory should be disabled by the "graft"
command, so that if users manipulate the subtree before committing,
their "adds", "mvs" and "removes" are applied to the root tree, not the
subtree.

I wonder whether it would be worthwile adding the ability for bzrdirs to
contain "old contents"?  That would allow us to revert "upgrade" as well
as "graft".  graft would simply move '.bzr/*' into '.bzr/old/1/', so
that WorkingTree.open_containing would continue upwards until it found
the new root.

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

iD8DBQFEexHS0F+nu1YWqI0RAmQ8AJ4uGXZjhIuruzthWRYDdfoHFjPqrQCfQYhw
UXq1YkupAKKuvT2maxvpnvA=
=xV0g
-----END PGP SIGNATURE-----