On Tue, Mar 30, 2010 at 06:14:50PM +0200, Stefan Sperling wrote:
> I want the storage layer to care about storage, not about policy.
FWIW, this diff changes the spec accordingly. Note how the "patch"
conflict type does not use the COMMON data at all.
Any really strong reason not to do it this way?
Note that my intention for the API is that we'll have fine-grained
functions to retreive data from skels of a specific conflict,
and then layer more general conflict-enquiry functions (which would
currently retrieve answers from COMMON only, except for patch I guess *cough*)
above these fine-grained functions. Callers of the general functions
would not get to see any redundantly stored data.
Index: notes/wc-ng/conflict-storage
===================================================================
--- notes/wc-ng/conflict-storage (revision 929178)
+++ notes/wc-ng/conflict-storage (working copy)
@@ -11,36 +11,22 @@
tree conflicts, patch conflicts, and obstructions). The conflict skel
has the form:
- (COMMON (KIND KIND-SPECIFIC) (KIND KIND-SPECIFIC) ...)
+ ((KIND KIND-SPECIFIC) (KIND KIND-SPECIFIC) ...)
where KIND is one of "text", "prop", "tree", "patch", or
"obstructed". KIND-SPECIFIC is specific to each KIND, and is detailed
-below. The COMMON skel contains data that is common to all KINDs, and
-is detailed below.
+below.
-### stsp: I think the COMMON block should appear at the start of each
-### type-specific block instead. For instance, if I apply a patch and
-### rejects are recorded by the "patch" operation on the node,
-### it does not hurt to allow update or merge operations on the node
-### while it still has a patch conflict recorded.
-### A similar situation is a text vs. prop conflicts. E.g. if a node
-### node has only property conflicts, why not allow an update or merge
-### which does not touch conflicted properties? Even if we do not want
-### to allow this, I think embedding this decision into the storage
-### layer design is a bad idea. We can make higher layers deal with it.
-### See also http://svn.haxx.se/dev/archive-2010-03/0646.shtml
-
### stsp: need conflict data format version info inside skel, too?
### or do we bump the entire wc.db format number if we need to tweak
### this?
###
### gstein sez: the KIND can become "text-2" or somesuch if we need to
### radically alter the kind-specific data. but we can easily append
-### information to the skel without much problem. adjusting the
-### COMMON skel shouldn't be hard, if appending is insufficient.
+### information to the skel without much problem.
-If the 'conflict_data' column is not NULL, then COMMON must exist and
-at least one KIND of conflict skel, describing the conflict(s).
+If the 'conflict_data' column is not NULL, then at least one
+one KIND of conflict skel must exist, describing the conflict(s).
Contrary to wc-1, wc-ng records sufficient information to help users
understand, in hindsight, which operation led to the conflict (as long
@@ -69,29 +55,12 @@
(which does not necessarily equal the current working version!)
-Common conflict data
---------------------
-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). The COMMON skel has the form:
+Common skel fields
+------------------
- (OPERATION LEFT_REV RIGHT_REV
- (LEFT_UUID LEFT_ROOT_URL LEFT_RELPATH LEFT_PEG_REV)
- (RIGHT_UUID RIGHT_ROOT_URL RIGHT_RELPATH RIGHT_PEG_REV) )
+Some fields appear in several KIND-SPECIFIC conflict skels:
-### BH: I don't know if all these values apply to obstructions and patch
-### conflicts. And most of these values are not available for conflicts
-### that are introduced via 1.6 (and some of our deprecated svn_wc apis)
-
-### stsp: We can simply use empty strings for fields which don't make
-### sense for the current conflict type.
-
-### BH: Should we have the (incoming_change local_change) block here?
-### BH: Should we have the (left_node_kind right_node_kind) block here?
-### BH: Do we need more data on 'older/mine' or is that handled via left/right?
-
OPERATION is "update", "switch", "merge", or "patch", indicating during what
type of operation the conflict occurred.
@@ -123,7 +92,10 @@
Text conflicts only exist on files. The following skel represents the
"text" KIND of conflict:
- ("text" LEFT_SHA1 RIGHT_SHA1 MINE_SHA1)
+ ("text" (OPERATION LEFT_REV RIGHT_REV)
+ (LEFT_UUID LEFT_ROOT_URL LEFT_RELPATH LEFT_PEG_REV)
+ (RIGHT_UUID RIGHT_ROOT_URL RIGHT_RELPATH RIGHT_PEG_REV)
+ LEFT_SHA1 RIGHT_SHA1 MINE_SHA1) )
### BH: We need some marker here, but these values must also be stored
### in the older_checksum, left_checksum, right_checksum colums of ACTUAL
@@ -147,7 +119,10 @@
by one or more "prop" KIND conflicts. Each "prop" conflict has the
following form:
- ("prop" PROPERTY_NAME ([LEFT_VALUE]) ([RIGHT_VALUE]) ([MINE_VALUE]))
+ ("prop" (OPERATION LEFT_REV RIGHT_REV)
+ (LEFT_UUID LEFT_ROOT_URL LEFT_RELPATH LEFT_PEG_REV)
+ (RIGHT_UUID RIGHT_ROOT_URL RIGHT_RELPATH RIGHT_PEG_REV)
+ PROPERTY_NAME ([LEFT_VALUE]) ([RIGHT_VALUE]) ([MINE_VALUE]))
PROPERTY_NAME is the name of the property, such as "svn:eol-style".
@@ -162,7 +137,9 @@
Tree conflicts exist on files or directories.
The following information is stored if there is a tree conflict on the node:
- ("tree"
+ ("tree" (OPERATION LEFT_REV RIGHT_REV)
+ (LEFT_UUID LEFT_ROOT_URL LEFT_RELPATH LEFT_PEG_REV)
+ (RIGHT_UUID RIGHT_ROOT_URL RIGHT_RELPATH RIGHT_PEG_REV)
INCOMING_CHANGE LOCAL_CHANGE
LEFT_NODE_KIND RIGHT_NODE_KIND
LEFT_SHA1 RIGHT_SHA1 MINE_SHA1)
@@ -200,7 +177,9 @@
There is no particular data which needs to be recorded for an
obstruction. Thus, the "obstructed" conflict skel has the form:
- ("obstructed")
+ ("obstructed" (OPERATION LEFT_REV RIGHT_REV)
+ (LEFT_UUID LEFT_ROOT_URL LEFT_RELPATH LEFT_PEG_REV)
+ (RIGHT_UUID RIGHT_ROOT_URL RIGHT_RELPATH RIGHT_PEG_REV) )
Patch conflicts (a.k.a. "rejects")
Received on 2010-03-30 19:15:13 CEST