You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2015/08/27 16:41:50 UTC
svn commit: r1698170 - /subversion/branches/move-tracking-2/BRANCH-README
Author: julianfoad
Date: Thu Aug 27 14:41:50 2015
New Revision: 1698170
URL: http://svn.apache.org/r1698170
Log:
On the 'move-tracking-2' branch: Update an old section in BRANCH-README.
* BRANCH-README
Update the 'update editor' section.
Modified:
subversion/branches/move-tracking-2/BRANCH-README
Modified: subversion/branches/move-tracking-2/BRANCH-README
URL: http://svn.apache.org/viewvc/subversion/branches/move-tracking-2/BRANCH-README?rev=1698170&r1=1698169&r2=1698170&view=diff
==============================================================================
--- subversion/branches/move-tracking-2/BRANCH-README (original)
+++ subversion/branches/move-tracking-2/BRANCH-README Thu Aug 27 14:41:50 2015
@@ -176,7 +176,7 @@ Work on this branch:
that is the same across all branches in a family?
- * A 'commit editor' interface supporting moves
+ * An 'editor' interface supporting moves
STATUS
@@ -195,7 +195,7 @@ Work on this branch:
svnlook test fails due to svnlook reporting a no-op change as a
change.)
- However, this version of the editory is not complete with respect to
+ However, this version of the editor is not complete with respect to
branching: it only provides the operations that are needed *within* a
branch. It could, I suppose, be extended to support operations on
branches, including both the 'branching' operation itself, and also
@@ -220,20 +220,15 @@ Work on this branch:
I think it's not a question of one way is right and one is wrong;
rather, both are possible correct approaches.
-
- * Adapt the editor as necessary to use as an 'update editor'.
-
- The 'update editor' has some significantly different requirements,
- at least the way it's implemented today with WC paths being
- communicated rather than repository paths/nodes. Need to work out
- how best to achieve this.
- My preference is to lean towards using a 'tree editor' working on
- repos nodes, and let the client side convert these to WC paths, but
- we'll have to see if that's practical.
-
- STATUS
-
- Not started.
+ This 'editor' can be used for 'commit', in which it edits a transaction
+ based on the 'head' revision, and for 'update', in which it edits a
+ transaction that represents the WC base (and then we merge this edit
+ with the WC base->working edit to update the WC working state).
+
+ (The original 'update editor' had a peculiarity in that it used the
+ same API underneath but operating on WC paths rather than repository
+ paths/nodes. We should try to use exactly the same API for update,
+ commit, diff, merge, etc. as far as possible.)
Terminology: