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?
Of course, the higher layer can still decide not to allow certain
things which would "conflict with the conflict".
"Because our current API does not allow you to do that" is not a good
argument for not taking the opportunity of making the storage layer more
flexible. We can easily add new APIs that allow partial conflict
resolution to take place on nodes. The old API would still work as is,
i.e. if you use 1.6.x function to query about conflicts, any conflict
set on the node will trigger a positive answer. But the new API would be
more fine-grained, and would allow detailed queries about the data
stored about conflicts. Policiy decisions then happen above the storage
layer.
Stefan
Received on 2010-03-30 16:30:50 CEST