You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2010/03/31 14:48:26 UTC
svn commit: r929511 - /subversion/trunk/notes/wc-ng/conflict-storage
Author: stsp
Date: Wed Mar 31 12:48:26 2010
New Revision: 929511
URL: http://svn.apache.org/viewvc?rev=929511&view=rev
Log:
* notes/wc-ng/conflict-storage: Various small tweaks, clarifying a few
details, removing obsolete content, moving some comments around to
where they now belong.
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=929511&r1=929510&r2=929511&view=diff
==============================================================================
--- subversion/trunk/notes/wc-ng/conflict-storage (original)
+++ subversion/trunk/notes/wc-ng/conflict-storage Wed Mar 31 12:48:26 2010
@@ -27,7 +27,7 @@ to each KIND, and is detailed below.
### information to the skel without much problem.
If the 'conflict_data' column is not NULL, then at least one
-one KIND of conflict skel must exist, describing the conflict(s).
+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
@@ -39,24 +39,6 @@ but this information can be deduced from
(e.g. conflict-old and friends; foo.r42 is now 'foo' + '.r' + left_rev)
-Terminology
---------------------
-
-There are 3 versions of an item involved in a conflict:
- left: During update, the 'left' version is the common ancestor
- of the 'right' and 'mine' versions.
- During merge, the 'left' version is the version of the item
- as it appears at the merge-left revision.
- right: During update, the 'right' version is the version of the item
- as it appears in the revision updated to.
- During merge, the 'right' version is the version of the item
- as it appears at the merge-right revision.
- mine: During both update and merge, this is the version of the item
- as found in the working copy when the conflict was detected
- (which does not necessarily equal the current working version!)
-
-
-
Operation skel
--------------
@@ -75,6 +57,7 @@ For update: (BASE_REV TARGET_REV)
For switch: (BASE_REV TARGET_REV REPOS_ROOT_URL REPOS_RELPATH)
+ BASE_REV and TARGET_REV are as for "update" above.
REPOS_ROOT_URL is the repository root of the URL being switched to.
REPOS_RELPATH is the path in the repository being switched to.
@@ -105,6 +88,11 @@ For patch: (PATCH_FILE_ABSPATH)
PATCH_FILE_ABSPATH is the absolute path of the patch file the
application of which led to conflicts.
+### gstein: why keep the PATCH_FILE_ABSPATH? couldn't that be rm'd at
+### some point after the attempted 'svn patch'? and doesn't this
+### obviate the future possibility of patch from stdin?
+### stsp: See http://svn.haxx.se/dev/archive-2010-03/0645.shtml
+
Text conflicts
--------------
@@ -114,6 +102,10 @@ Text conflicts only exist on files. The
("text" LEFT_SHA1 RIGHT_SHA1 MINE_SHA1)
+{LEFT,RIGHT,MINE}_SHA1 are sha1 checksums of the full texts of
+the {left,right,mine} version of the file. File version's content
+can be obtained from the pristine store.
+
### 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.
@@ -123,10 +115,6 @@ Text conflicts only exist on files. The
### and symlinks are resolved before the SHA1 is calculated and
### stored in the db?
-{LEFT,RIGHT,MINE}_SHA1 are sha1 checksums of the full texts of
-the {left,right,mine} version of the file. File version's content
-can be obtained from the pristine store.
-
Property conflicts
--------------
@@ -197,6 +185,8 @@ Reject conflicts
For patches, the content of the left and right versions is not fully known,
so the conflict is not a diff3-style text conflict. Rather, the conflict
is the failure to find a match for a hunk's context in the patch target.
+There can be one or more reject conflicts on a node. Each "reject" conflict
+has the following form:
("reject"
HUNK_ORIGINAL_OFFSET HUNK_ORIGINAL_LEN
@@ -220,8 +210,3 @@ hunk as written to the .svnpatch.rej fil
### the user deletes the tempfile would be nice. And I don't see an issue
### with also storing the SHA1 sum in the ACTUAL table. We do this for
### text conflicts as well. Why would it need an extra table?
-
-### gstein: why keep the PATCH_FILE_ABSPATH? couldn't that be rm'd at
-### some point after the attempted 'svn patch'? and doesn't this
-### obviate the future possibility of patch from stdin?
-### stsp: See http://svn.haxx.se/dev/archive-2010-03/0645.shtml