[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-conflicts
Subject:    Re: [darcs-conflicts] An alternative to conflictors?
From:       Arjan Boeijink <w.a.boeijink () student ! utwente ! nl>
Date:       2005-12-09 16:56:59
Message-ID: 4399B75B.2050003 () student ! utwente ! nl
[Download RAW message or body]

David Roundy wrote:

>By delaying until the conflict is resolved, you mean it's not automatically
>resolved, but a human chooses, right? 
>
Yes.

>It seems that you aren't envisioning
>this resolution as creating a new patch with a new identity (correct me if
>I'm wrong).  This will cause trouble because it means that the state of a
>repository is no longer determined by its set of patches, which is very
>close to the core of how darcs works.  You'd need some other way to
>describe the state of a repository, which would be bizarre (and I think
>this is why you run into trouble thinking about the merge of two different
>conflict resolutions).
>  
>
Sorry I wasn't clear about this in my email. But i see conflict 
resolution (and rollback as well) as creating a new patch with a new 
identity that is an annotation of a patch that may turn off or on the 
effect of the annotated patch.

>If you add a new patch identity to represent the "resolution", you'll have
>to decide whether it's a modification of the original patch, or an
>separate patch (as it is in current darcs).  If you go with the latter
>(which I doubt would be your choice), I think your theory would end up
>morphing into conflictors.  The former looks sort of like what you're doing
>with your generation number, but as you point out, it seems like a rather
>limited way of doing the resolution.
>  
>
Resolution annotation patches are separate patches but before 
manipulating a patch sequence all annotation are attached to their 
corresponding patch and then worked with as a single entity with the 
annotated patch. In my previous mail I only described the cases where 
the annotations were already attached. A generation number is only a 
primitive way to express which annotation is the strongest when one of 
them turn the effect of patch a off and the other turns it on. I know 
it's way too crude but I haven't worked out yet a scheme that captures 
the intend of a resolution annotation better.

>There's also some question (which could be deferred) as to whether the
>primitive patch has a modified identity or a composite identity does.
>Since darcs high-level code relies on the composite identity (plus, that's
>what users want to think about, I believe), you'd need to make sure when
>there's a conflict that the high-level identity is modified to take into
>account the resolution of particular primitive patches.
>  
>
I haven't really thought about this yet, but I think composite patches 
shouldn't introduce more conflicts than when they are all primitive patches.

>As I look at it (and your ideas have a distinct appeal--particularly as a
>backup plan if we can't figure out how to make conflictors work), it seems
>that your idea basically adds a new degree of freedom to a repository, so
>that a repository will now consist of a set of patches and a generation
>number for each patch.  When comparing repositories, their state would be
>identical if they have an identical set of patches *and* generations.  The
>confusing part is that the generations seem to change without any
>versioning going on.  True, tags could record what each patch's generation
>is, so we could reproduced any tagged version, but no comment is associated
>with generation changes, as far as I can tell, and that's a bit disturbing.
>It's also convenient, since it means that if two people choose the same
>resolution of a conflict, they end up generating identical patches.  I
>suppose we could generate a tag (or something similar to a tag) whenever a
>conflict is resolved, which would give the user a chance to add some
>comments, but like tags, wouldn't be able to conflict, so two users
>resolving a conflict the same way would generate two conflict resolution
>messages, but only one conflict resolution.
>
One could view a repository as a set of patches and a set of resolution 
annotations determining which patches have effect, though I don't think 
that helps in reasoning about it. Annotation patches are versioned at 
least in the sense that you can always add one more that overrides the 
meaning of the previous annotations of the same patch. I think it's 
important to always merge without conflict if two individual annotation 
patches have the same meaning. How to deal with patches having multiple 
identities and comments should be only a user interface problem. It 
would be nice to have some form of individual patch convergence of 
normal patches also.

-- Arjan

_______________________________________________
darcs-conflicts mailing list
darcs-conflicts@darcs.net
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-conflicts
[prev in list] [next in list] [prev in thread] [next in thread]