[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: what is Ben working on?

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-07 00:44:30 CET

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.



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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.