[MERGE] bug #54172: revert handles new directories nicely
aaron.bentley at utoronto.ca
Tue Aug 29 18:25:36 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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 :-)
> 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
I agree the message should be improved, but it's not a superficial
change. It means work on the conflict resolver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar