On Fri, Jan 25, 2002 at 04:39:03PM -0600, Ben Collins-Sussman wrote:
>...
> 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.
I'm not sure whether "building a mirror" is portable across RA providers
(future/conceptual, mainly). And I know that breaking that step out in the
ra_dav case could be a bit problematic.
>...
> 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.
Ah... gotcha. Well... if you can think up a good name :-)
>...
> > 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.
Yes, they would be cleaned up together, but every stringbuf is a good chunk
of additional work. Gotta change the implementation, the header files, the
callers, etc.
> Until that happens, I thought consistency (readability) was
> more important. But I can change that.
I'll take the inconsistency since we know where we're going. If somebody
gets bugged, then they can speed up the stringbuf work.
Don't bother changing it... the time to change is either you, or whoever is
doing the stringbuf change later. Net result is still the same, so no sense
in having you go and do this one now (and creating the consistency issue).
>...
> > > + /* 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.
Your call. Consider it a nit. Maybe if you in there, a "for example" might
be enough. Mostly, I was just responding to the presence of client ops
rather than explanations based on semantics. No biggy.
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:00 2006