> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 30 maart 2010 16:30
> To: dev_at_subversion.apache.org
> Cc: commits_at_subversion.apache.org
> Subject: allowing multiple conflicts in storage (Re: svn commit: r928806 -
> /subversion/trunk/notes/wc-ng/conflict-storage)
>
> On Mon, Mar 29, 2010 at 03:37:51PM -0000, rhuijben_at_apache.org wrote:
> > Author: rhuijben
> > Date: Mon Mar 29 15:37:50 2010
> > New Revision: 928806
> >
> > URL: http://svn.apache.org/viewvc?rev=928806&view=rev
> > Log:
> > * notes/wc-ng/conflict-storage
> > Update schema to have some global information that applies to all
> > conflict data. Remove this data from the individual locations as it
> > can't differ between these locations anyway (or the node would have
> > been skipped). Finally add unversioned obstructions as a conflict
> > class.
>
> > -Text conflicts
> > ---------------
> > +Common conflict data
> > +--------------------
> >
> > -Text conflicts only exist on files. The following information
> > -is stored if there is a text conflict on the node:
> > +Some information is shared for all conflict data that applies to a
node. E.g.
> > +when a node has a combination of text and property conflicts these were
> > +always caused by the same operation. (Any later operation will skip the
> node
> > +unless the conflicts are resolved)
> >
>
> I'm still not sure that I agree with this.
>
> I don't think it's smart to restrict the conflict storage layer
> to accept only a single set of conflicts for a node, all of which
> belong together to the point where you cannot do anything to the
> node unless you have resolved *all* conflicts.
>
> I'd like the storage layer to allow for resolving each type of conflicts
> separately from the other types. Higher-level operations can then decide
> whether it is safe to do something to the partially-conflicted node.
> E.g. if a file has only property conflicts, why should a merge skip
> merging changes into the file itself? If a directory is tree conflicted,
> why should I not be allowed to merge some content into a file below
> the tree-conflicted directory if doing so helps me to resolve the tree
> conflict?
I intended to allow resolving only some parts of the conflict; but we can't
allow operations that can introduce conflicts on their own.
You can't apply a merge/update/switch/patch on a node that has a
text/property/obstruction/patch conflict, because a can cause a conflict
with the conflict state (How would you describe that?). You can't trust the
in-wc state if you have a conflict.
In 1.6 the way to resolve a text conflict is to edit the in-wc text with all
the information provided and then mark it resolved.
The same applies to properties: You read the '.prej' file and decide what
the new property value(s) must be and you mark all resolved. (Or just one
with the new storage).
But that doesn't make it possible to introduce new conflicts on top of
existing conflicts; that is +- impossible.
Just looking at text conflicts: merging will fail because you see conflict
markers.
Same applies to property merges: You can't merge a single property change
into the WC. (Would you use left, right or mine?)
Patch conflicts... see text conflicts.
Tree conflicts: Do you apply the change on BASE_NODE, or on WORKING_NODE
when the node is in a tree conflict?
Obstructions: You can't do anything to the in-wc data
What do we have left?
This is exactly why you need interactive conflict resolution while merging:
That is the only way you can continue a compound operation.
Bert
Received on 2010-03-30 17:55:36 CEST