"Julio M. Merino Vidal" <[EMAIL PROTECTED]> 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/>). _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel