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: Wed, 8 Aug 2007 13:09:19 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Aug 08, 2007 at 11:08:36AM -0600, Derek Scherger wrote:
> Nathaniel Smith wrote:
> > Question at hand is whether we would hit a sweeter spot on that
> > predictability/usefulness trade-off if we made content edits conflict
> > with file deletes.
> 
> A few months ago I was wondering what we do with the content marks when
> merging with deletes. I'm not even sure we would *have* a content mark
> available on the deleted side to compare with the not-deleted side
> though. The node on the deleted side is gone and so are the marks.

Right, and that's why I initially thought it was impossible.

> It seems at least somewhat sensible that a delete verses a content
> change should be a conflict while a delete verses no content change
> should not. We probably don't want this for name or attribute changes
> though.

But we can get this behavior through a little trick.  If you think
about it, the marks on a scalar basically tell you whether that scalar
should win, and a conflict is when both sides want to win.  When we
have an edit/delete conflict, well, obviously we know the delete side
wants to win, we can tell that from the birth mark alone.  The
question is whether the live side has content changes that the dead
side hasn't seen yet.  But to determine that, all we need is the mark
on the live side...

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein




reply via email to

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