[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Lack of conflicts checking
From: |
Thomas Moschny |
Subject: |
Re: [Monotone-devel] Lack of conflicts checking |
Date: |
Mon, 6 Aug 2007 18:03:51 +0200 |
User-agent: |
KMail/1.9.7 |
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.