On Mon, Mar 29, 2010 at 03:37:51PM -0000, rhuij...@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