subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rhuij...@apache.org
Subject svn commit: r928806 - /subversion/trunk/notes/wc-ng/conflict-storage
Date Mon, 29 Mar 2010 15:37:51 GMT
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.

Modified:
    subversion/trunk/notes/wc-ng/conflict-storage

Modified: subversion/trunk/notes/wc-ng/conflict-storage
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/conflict-storage?rev=928806&r1=928805&r2=928806&view=diff
==============================================================================
--- subversion/trunk/notes/wc-ng/conflict-storage (original)
+++ subversion/trunk/notes/wc-ng/conflict-storage Mon Mar 29 15:37:50 2010
@@ -11,8 +11,8 @@ conflict information, or NULL (meaning n
 There are 4 types of conflicts (text conflicts, property conflicts,
 tree conflicts, patch conflicts), so the skel contains the following
 lists in order:
-( (text conflict data) (prop conflict data) (tree conflict data) (patch
-    conflict data) )
+( (common conflict data) (text conflict data) (prop conflict data)
+  (tree conflict data) (obstruction data) (patch conflict data) )
 ### 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?
 If the 'conflict_data' column is not NULL, at least one of these
@@ -42,17 +42,26 @@ There are 3 versions of an item involved
         as found in the working copy when the conflict was detected
         (which does not necessarily equal the current working version!)
 
-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)
 
 ( (operation)
   (left_rev right_rev)
   (left_repos_uuid left_repos_root_url left_path_in_repos left_peg_rev)
-  (right_repos_uuid right_repos_root_url right_path_in_repos right_peg_rev)
-  (left_sha1 right_sha1 mine_sha1) )
+  (right_repos_uuid right_repos_root_url right_path_in_repos right_peg_rev) )
+
+### 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)
+
+### 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", or "merge", indicating during what
 type of operation the conflict occurred.
@@ -79,41 +88,35 @@ of the item.
 the {left,right,mine} version of the file. File version's content
 can be obtained from the pristine store.
 
+Text conflicts
+--------------
+
+Text conflicts only exist on files. The following information
+is stored if there is a text conflict on the node:
+
+( (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
+###     to allow pristine store cleanups.
+
+### BH: What about symlinks?
+
 Property conflicts
 --------------
 
-Property conflicts can exist on files and directories.
-There can be one or more property conflicts on the node,
+Property conflicts can exist on files, directories and symlinks.
+There can be  or more property conflicts on the node,
 so property conflict data is a list. For each property conflict,
-an item exists in the list, storing the following information:
+an item exists in the list:
 
-( (operation)
-  (left_rev right_rev)
-  (left_repos_uuid left_repos_root_url left_path_in_repos left_peg_rev)
-  (right_repos_uuid right_repos_root_url right_path_in_repos right_peg_rev)
-  (incoming_change local_change)
-  (property_name)
-  (left_value right_value mine_value) )
-   
-'operation' see text conflicts
-'{left,right}_rev' see text conflicts
-
-'{left,right}_repos_uuid' see text conflicts
-'{left,right}_repos_root_url' see text conflicts
-'{left,right}_path_in_repos' see text conflicts
+( ( ( (property_name) (left_value) (right_value) (mine_value) ) )... ) )
 
 'property_name' is the name of the property, such as "svn:eol-style".
 
-'incoming_change' is the incoming change which conflicted with the
-local change during the operation. Possible values are "edit", "add",
-and "delete".
-
-'local_change' is the local change which conflicted with the
-incoming change during the operation. Possible values are "edit", "add",
-and "delete".
-
 '{left,right,mine}_value' is the value of the {left,right,mine}
-version of the property.
+version of the property. An empty item specifies that the property
+does not exist in that version.
 
 Tree conflicts
 --------------
@@ -121,21 +124,10 @@ Tree conflicts
 Tree conflicts exist on files or directories.
 The following information is stored if there is a tree conflict on the node:
 
-( (operation)
-  (left_rev right_rev)
-  (left_repos_uuid left_repos_root_url left_path_in_repos left_peg_rev)
-  (right_repos_uuid right_repos_root_url right_path_in_repos right_peg_rev)
-  (incoming_change local_change)
+( (incoming_change local_change)
   (left_node_kind right_node_kind)
   (left_sha1 right_sha1 mine_sha1) )
 
-'operation' see text conflicts
-'{left,right}_rev' see text conflicts
-
-'{left,right}_repos_uuid' see text conflicts
-'{left,right}_repos_root_url' see text conflicts
-'{left,right}_path_in_repos' see text conflicts
-
 'incoming_change' is the incoming change which conflicted with the
 local change during the operation. Possible values are "edit", "add",
 "delete", "rename", and "replace".
@@ -149,6 +141,25 @@ of that file is known, '{left,right,mine
 full text of the {left,right,mine} version of the file. The file version's
 content can be obtained from the pristine store.
 
+### BH: We need to duplicate the sha1 values in the older_checksum,
+###     left_checksum, right_checksum colums of ACTUAL
+###     to allow pristine store cleanups.
+
+### BH: Can we share some of the sha1 logic with the text conflicts to
+###     allow resolving this in the same way?
+###     (We should keep the history of the node valid via replace vs update)
+
+(Unversioned) Obstructions
+--------------------------
+
+When an update introduces a new node where an existing node is
+stored locally we need to add some marker to allow the operation to update
+the BASE_NODE table.
+
+### BH: I don't think we need specific data here; just a boolean?
+### It is always a conflict between the IN-WC data and the local WC.
+
+
 Patch conflicts (a.k.a. "rejects")
 ----------------------------------
 For patches, the content of the left and right versions is not fully known,
@@ -171,3 +182,8 @@ diff text but are stored here for easy r
 'reject_diff_sha1' is the sha1 of the unidiff content of the rejected
 hunk as written to the .svnpatch.rej file. The actual unidiff content
 (which can be large!) can be retrieved from the pristine store.
+
+### BH: Using a sha1 here, makes it impossible to cleanup the pristine store
+###     The pristine store needs all references to be stored in a DB column.
+###     To support this we would need an extra table.
+



Mime
View raw message