[Monotone-devel] Re: Lack of conflicts checking

[Bruce Stephens]

"Julio M. Merino Vidal" <address@hidden> writes:

[...]

> Which to me is incorrect because I expected it to raise some form of
> conflict.  After all, those changes made to the dropped file were
> also supposed to be migrated to the new file.  (I knew this, but
> imagine the fix had been done by a second user.  I could not have
> noticed, and Monotone could have not told me.)
>
> Is my reasoning correct and Monotone is lacking some kind of
> conflicts checking here?

How should monotone know that you migrated things from the dropped
file to another file?

Had you renamed the file then everything would have worked OK (but
then you wouldn't have dropped the old name, so I guess it's a
different situation).

I suppose monotone could warn (or give a conflict) if, when merging, a
file has been modified in one branch and dropped in another, on the
grounds that the modifications might be significant in some way and so
shouldn't be silently dropped.  That seems likely to lead to lots more
false-positives than would be useful, though.

The false-positives could be reduced using git-style content-guessing.
That is, you use not just knowledge about file names and things, but
actually look at the contents to try to deduce whether content has
been moved.  That seems plausible enough, and maybe you could add in
some git-style merge guessing (merging changes to such moved content).

Hard to convince oneself about any properties of such a scheme, I
guess.  Using explicit file renaming and also content-guessing appears
to be something that bzr people are considering (or at least blogging
about the possibility of,
<http://ianclatworthy.wordpress.com/2007/07/30/version-control-design-for-integration/>).