Author: julianfoad
Date: Fri Feb 23 15:39:00 2018
New Revision: 1825134
URL: http://svn.apache.org/viewvc?rev=1825134&view=rev
Log:
* subversion/libsvn_client/client.h
Update a really old comment, and fix spelling.
Modified:
subversion/trunk/subversion/libsvn_client/client.h
Modified: subversion/trunk/subversion/libsvn_client/client.h
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/client.h?rev=1825134&r1=1825133&r2=1825134&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_client/client.h (original)
+++ subversion/trunk/subversion/libsvn_client/client.h Fri Feb 23 15:39:00 2018
@@ -754,40 +754,23 @@ typedef struct svn_client__copy_pair_t
/*** Commit Stuff ***/
-/* WARNING: This is all new, untested, un-peer-reviewed conceptual
- stuff.
+/* The "Harvest Committables" System
- The day that 'svn switch' came into existence, our old commit
- crawler (svn_wc_crawl_local_mods) became obsolete. It relied far
- too heavily on the on-disk hierarchy of files and directories, and
- simply had no way to support disjoint working copy trees or nest
- working copies. The primary reason for this is that commit
- process, in order to guarantee atomicity, is a single drive of a
+ The commit process requires, per repository, a single drive of a
commit editor which is based not on working copy paths, but on
- URLs. With the completion of 'svn switch', it became all too
- likely that the on-disk working copy hierarchy would no longer be
- guaranteed to map to a similar in-repository hierarchy.
-
- Aside from this new brokenness of the old system, an unrelated
- feature request had cropped up -- the ability to know in advance of
- your commit, exactly what would be committed (so that log messages
- could be initially populated with this information). Since the old
- crawler discovered commit candidates while in the process of
- committing, it was impossible to harvest this information upfront.
- As a workaround, svn_wc_statuses() was used to stat the whole
- working copy for changes before the commit started...and then the
- commit would again stat the whole tree for changes.
-
- Enter the new system.
+ URLs. The on-disk working copy hierarchy does not, in general,
+ map to a similar in-repository hierarchy, due to switched subtrees
+ and disjoint working copies.
+
+ Also we wish to know exactly what would be committed, in advance of
+ the commit, so that a log message editor can be initially populated
+ with this information.
The primary goal of this system is very straightforward: harvest
all commit candidate information up front, and cache enough info in
the process to use this to drive a URL-sorted commit.
- *** END-OF-KNOWLEDGE ***
-
- The prototypes below are still in development. In general, the
- idea is that commit-y processes ('svn mkdir URL', 'svn delete URL',
+ The idea is that commit-y processes ('svn mkdir URL', 'svn delete URL',
'svn commit', 'svn copy WC_PATH URL', 'svn copy URL1 URL2', 'svn
move URL1 URL2', others?) generate the cached commit candidate
information, and hand this information off to a consumer which is
@@ -844,7 +827,7 @@ typedef svn_error_t *(*svn_client__check
- if the candidate has a lock token, add it to the LOCK_TOKENS hash.
- if the candidate is a directory scheduled for deletion, crawl
- the directories children recursively for any lock tokens and
+ the directory's children recursively for any lock tokens and
add them to the LOCK_TOKENS array.
At the successful return of this function, COMMITTABLES will point
