On Wed, Feb 06, 2002 at 04:54:53PM -0600, Ben Collins-Sussman wrote:
>...
> 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()
Um. "massive" is an understatement :-)
I'm glad you're in there working on that thing. A bit of refactoring could
do it some real good.
>...
> /* Given a FILE_PATH already under version control, fully "install" a
> NEW_REVISION of the file.
I presume this function is only for files, not directories?
> 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.
I'm a bit unclear on the output. Is it simply that the logfile associated
with this file will contain the relevant actions? That some post-process
will still need to run the log? Or does the log actually get run before this
function returns?
[ I would hope yes, so that we can batch a bunch of calls to install_file ]
Is install_file going to be used for both switch and commit? Or does this
simply defer to an internal routine used by both processes?
>...
> 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
>
Incomplete comment?
Big request: can't we keep a single hash of properties? The internals of
this function can do the sorting of property types. I would *much* rather
see our public APIs not differentiate/expose the property types.
> svn_error_t *svn_wc_install_file (svn_stringbuf_t *file_path,
> svn_revnum_t *new_revision,
> svn_stringbuf_t *new_text_path,
How about 'const char *' for the paths. If the internals need a buf (for
now), then you can quickly put one together.
Should that new_revision just be 'svn_revnum_t' (no indirection) ?
>...
> 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.
Cool...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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