I'm still working on getting 'svn switch' to work on a single file.
We all agree on how to do it: just do an RA->get_file on the thing;
don't try to use any editors.
But the tricky part is now trying to *integrate* the new data into the
working copy. It means that the massive update-editor's close_file()
needs to be put into a public routine, because close_file() will call
it, but so will svn_client_switch(). Here's the prototype:
/* Given a FILE_PATH already under version control, fully "install" a
NEW_REVISION of the file.
By "install", we mean: the working copy library creates a new
text-base and prop-base, merges any textual and property changes
into the working file, and finally updates all metadata so that the
working copy believes it has a new working revision of the file.
All of this work includes being sensitive to eol translation,
keyword substitution, and performing all actions using a journaled
logfile.
The caller provides a NEW_TEXT_PATH which points to a temporary
file containing the full text of the file at revision
NEW_REVISION. This function automatically removes NEW_TEXT_PATH
upon successful completion.
The caller also provides the full complement of properties for the
new file in PROPS, WCPROPS, and ENTRYPROPS (see 'props' section
below, and svn_types.h). These hashes map (const char *) names to
(svn_stringbuf_t *) values. Please note that these properties
hashes need not be complete: they can represent
POOL is used for all bookkeeping work during the installation.
*/
svn_error_t *svn_wc_install_file (svn_stringbuf_t *file_path,
svn_revnum_t *new_revision,
svn_stringbuf_t *new_text_path,
apr_hash_t *props,
apr_hash_t *wcprops,
apr_hash_t *entryprops,
apr_pool_t *pool);
So I'm now a tad mired down in walking through all the code that was
formerly in close_file(), trying to abstract it as much as possible.
I'm discovering that there are lots of minor shockwaves happening.
But hey -- it's all Goodness. In general, things are getting smaller
and cleaner as a result.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006