Greg Stein <gstein@lyra.org> writes:
> >...
> > /* 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?
Yeah. Hence the term "FILE_PATH", phrase "the file", and the name of
the function being named 'install_file'. But maybe the doc string
should just outright say it? :-)
> > 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?
It means that all the work is performed in a journall-y way;
i.e. actions are written to a log, then the log is executed. By the
time the function returns, work is complete and the log no longer
exists.
> 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?
svn_wc_install_file() is public, because svn_client_switch() needs to
call it when fetching a single file. But it's also 90% of the
functionality of the update-editor's close_file().
It's not used by commit at all; the post-commit process is a bit
different that the 'receive an update' process. I can go into detail
if you want...
> 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.
Yeah. There's actually a much Bigger Change that Mike/Karl/I have
been discussing, which we like to propose as another changeset to
follow this one. Something close to what you're saying -- somehow
have all props live in one hash, but then librarize some routines that
parse them and store them in different places.
Mike is wanting some kind of universal struct like this:
typedef struct svn_prop_t
{
const char *name,
svn_stringbuf_t *value,
enum prop_kind kind;
}
The idea here is that these are the objects that the client deals
with; when travelling over the wire, we have functions that 'parse'
and 'unparse' the names by adding or removing proper prefixes.
(Actually, more than that: some DAV: props map to totally different
names in the working copy. Our parse/unparse routines would cover
those too.)
> > 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.
Sure.
---------------------------------------------------------------------
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