monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Lack of conflicts checking


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Lack of conflicts checking
Date: Tue, 7 Aug 2007 18:50:34 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, Aug 06, 2007 at 05:40:28PM +0200, 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:
> 
[merged a delete with a content edit]
> Is my reasoning correct and Monotone is lacking some kind of  
> conflicts checking here?

Monotone is working as designed.  (Which is pretty much a given, since
there are like eleventy-million tests for all the merge code.)

So why was it designed this way?  It was designed this way mostly
because when I wrote the code, I couldn't figure out how to get the
behavior you want -- once a file is deleted, we forget everything
about it, including the metadata normally used to figure out how to
merge the file contents, so how can we even notice that there was a
content conflict?  Then I justified this by saying, well, besides,
it'd be really annoying in cases where for instance you are replacing
a subsystem in a branch, and have deleted the old cruddy version, and
then every time you merge in from mainline you have to resolve a ton
of pointless edit vs. delete conflicts.

I thought this justification was compelling, but then I realized that
actually it is really easy for the merger to detect an edit vs. delete
conflict.  (The trick, for other mtn hackers: If the content mark on
the live side is an uncommon ancestor of that side, then the edit
occurred more recently than the delete.  Probably some of you already
noticed this yourselves.)  Having realized that, I suddenly find my
justification not very convincing at all, which is a bit unsettling.

Anyway: Technically we *could* start detecting that conflict you
describe, end-user-wise I could be convinced that we *should* start
detecting that conflict you describe, and also there is some question
to be resolved over how we would report such conflicts to the user
(they have the funny property that there's really not that much that
can be done to resolve them, the file is dead).

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould




reply via email to

[Prev in Thread] Current Thread [Next in Thread]