Greg Stein <gstein@lyra.org> writes:
> On Fri, Jan 25, 2002 at 03:43:37PM -0600, sussman@tigris.org wrote:
> >...
> > Begin work on network-side of 'svn switch'. I know that we may be
> > refactorizing the RA interface later on, but we can still get 'switch'
> > working with what we have.
>
> Eh? What is this refactor? What changes in the RA interface are needed?
There's an idea batting around about making a new RA function which
builds a mirror of the working copy on the server -- in other words,
just the 'report' phase. This RA function would be shared by client
functions implementing update/switch/status. This routine would
return a baton (containing the txn) that would be passed to
RA->do_update, do_switch, do_status.
But that's just an idea.
>
> >...
> > * svn_repos.h (svn_repos_begin_report): require new 'switch_path' field.
>
> Eek. That is a "target path" or something. It is not a "switch" path. We
> don't want to imply that the path is only for switches. It is a generic
> argument to specify a second path for the delta operation.
>
> Please think in the abstract, rather than in your concrete case :-)
I originally called the new argument 'target_path'. The problem is
that it's right next to an argument called 'target', as in
"anchor/target". I thought it was confusing.
But you're right -- maybe there's a general name out there we can use,
that doesn't use the phrase "target". I'll gladly change it.
>
> >...
> > +++ NEW/trunk/subversion/include/svn_repos.h Fri Jan 25 15:43:26 2002
> > @@ -121,6 +121,10 @@
> > component, used to limit the scope of the update to a single entry
> > of FS_BASE, or NULL if all of FS_BASE is meant to be updated.
> >
> > + SWITCH_PATH is the fs path that the working copy should be
> > + transformed into. (In the case of updates, the caller should make
> > + sure it's identical to FS_BASE or FS_BASE/TARGET.)
>
> The comment should be independent of the "working copy". This is about
> generating a delta which describes a way to change the reported state into a
> different PATH/REV.
Right. Totally agree. This is svn_repos.h. I'll fix it.
>
> >...
> > + svn_error_t *(*do_switch) (void *session_baton,
> > + const svn_ra_reporter_t **reporter,
> > + void **report_baton,
> > + svn_revnum_t revision_to_update_to,
> > + svn_stringbuf_t *update_target,
> > + svn_boolean_t recurse,
> > + svn_stringbuf_t *switch_url,
> > + const svn_delta_edit_fns_t *update_editor,
> > + void *update_baton);
>
> It would be nice to not propagate the stringbuf types on new code.
I agree... but weigh that against consistency. Is it worse to have a
new stringbuf, or worse to have an API that takes a mixture of
stringbuf's and const char *'s? My thought was that whenever somebody
comes through doing stringbuf cleanup, they'll both be cleaned up
together. Until that happens, I thought consistency (readability) was
more important. But I can change that.
>
> >...
> > +++ NEW/trunk/subversion/libsvn_repos/reporter.c Fri Jan 25 15:43:35 2002
> >...
> > + /* The fs path that will be the 'target' of dir_delta.
> > + In the case of 'svn switch', this is probably distinct from BASE_PATH.
> > + In the case of 'svn update', this is should be identical to BASE_PATH */
> > + const char *switch_path;
>
> We really shouldn't be talking in terms of client operations, but in terms
> of what the API actually does/performs.
Isn't the first line of the comment exactly that? It says that it
will be passed to dir_delta, which is exactly about the reporter's
functionality.
I can remove the switch/update comments if you wish. I was just
trying to give some perspective.
---------------------------------------------------------------------
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:00 2006