Re: [Monotone-devel] Lack of conflicts checking

[Thomas Moschny]

On Monday 06 August 2007, Julio M. Merino Vidal wrote:
> Hi!
>
> I just got into a situation where Monotone did not report any error
> nor warning to me, even though I expected it to do so.  What I did is
> the following:
>
> - I had a workspace in which I dropped a file, because I migrated its
>    contents into another one.
> - I then detected a bug in the dropped file.
> - Following the daggy fixes methodology, I checked out a new workspace
>    and fixed that bug where it was introduced.
> - I committed this second workspace and merged the two heads.
> - Later, I went to the first workspace and ran update.
> - Monotone did not complain at all about the change in the dropped file.
>    All I got was:
>
> mtn: selected update target 19a3e7c3850ad49713980b203d7102b85a529576
> mtn: updated to base revision 19a3e7c3850ad49713980b203d7102b85a529576
>
> 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?

The problem is that monotone uses the DieDieDie merge strategy for aliveness 
of files, see http://revctrl.org/DieDieDieMerge. So, in every merge, a drop 
always wins.

This is bad from a user pov, but not easy so solve. There are some ideas, but 
imho no one has coded something yet.

Best,
Thomas M.

signature.asc
Description: This is a digitally signed message part.