[MERGE] bug #54172: revert handles new directories nicely

[Aaron Bentley]

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

John Arbash Meinel wrote:
> 1) A renamed directory will be removed.
> 
> So you did a merge, and then renamed the directory to somewhere else.
> That is technically a content change.

Not to my thinking.  That's moving an entry.

> I suppose there isn't a content change of z, so this is okay. Especially
> since the file would become unversioned anyway, we would lose the
> associated file id, and thus wouldn't be able to track a rename.
> 
> So I'm okay with that. And I guess for directories, we can just be
> consistent, that a revert nukes renames.

Yes, it does throw away a little data.  But it's only a little data.
The location of a directory (or file or symlink) is not a lot of data,
and it's not hard to manually reproduce.

To my thinking, the reason we retain modified files is because their
contents may be hard to manually reproduce.

> 2) This is more important, and that is that we will always nuke symlinks.

I agree that it will nuke symlinks.

> Now there was a content change to 'z' but it still gets removed by the
> revert step. I'm not hyper critical of this, but it seems risky. In our
> other handling of symlinks, we tended to substitute the symlink target
> in place of the sha1 sum. Could we put the target into the
> 'merge_modified' dictionary without really hosing anything?

Most likely.  The risk of collisions is slight, and if we add a prefix
that contains a character with a non-hex digit, we can make that impossible.

> It may be good to do this as part of a working tree format bump. For
> now, I think I prefer removing the symlink than keeping it, because it
> reduces clutter. But if we want to be more in a 'never lose anything',
> then we should not remove symlinks until we can tell that their content
> hasn't changed.

Yeah, I wasn't really trying to 'never lose anything'.  The idea was to
never lose anything that's hard to restore.

All of this is just a workaround for the fact that revert doesn't
produce bundles.  So I'd prefer to do THAT for the format bump instead.

> 3) Directories with sub-files.
> There is a bug here, that the conflict statement is wrong:
...
> Conflict adding files to s.  Not deleting.

Ah, but that bug has a different id assigned to it :-)
https://launchpad.net/products/bzr/+bug/47764

> So I guess my only real concern is that this change now deletes symlinks
> that have been modified. And that Conflicts should give better error
> messages.

I agree the message should be improved, but it's not a superficial
change.  It means work on the conflict resolver.

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

iD8DBQFE9HiQ0F+nu1YWqI0RAkhMAJ95NLWzyc9UJm+OQjUDZiusndeOVACfTy/h
yZm+KgsYMA7JNhVGUnOIurE=
=nlbW
-----END PGP SIGNATURE-----