Re: PATCH: "revision" parameter to svn_client_status

C.Michael Pilato wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>1) I'm pretty certain that my patch didn't change the level of
>>atomicity of any current Subversion client operation (with the
>>possible exception of status on externals).
>
> If svn_client_status is now *not* getting a hard revision number,
> that's bad. We don't want 'svn status -u foo bar' to get two different
> version numbers for 'foo' and 'bar' because someone committed while
> 'foo's status was coming down.

It doesn't matter whether this function gets itself a hard number ... oh, you mean it should be GIVEN a hard number by its caller. In that way, the caller can call it multiple times with the same number each time. Yes, that would solve the multiple-targets case.

That's a good idea for an improvement ... might even call it a bug to fix. If we care about the optimisation, the caller (svn_cl__status) could resolve the revision number of HEAD if it is going to process multiple targets, or leave it to default, saving a network round trip, if it is only going to process one target.

> On the flip side, if 'foo' and 'bar' represent paths in two different
> repositories, a single fetch of "the revision that is HEAD" won't do
> -- but this might be something to address later.

I would expect this to be handled as if two separate commands were issues by the user, one for each repository. That's how it works already. You're not implying a desire for atomic operation involving multiple repositories, are you? I hope you just meant that the future code to collect multiple targets into a single transaction must take care not to collect targets from different repositories together.

>>2) I'd still be interested to know whether ra_dav:make_reporter is
>>atomic when it does not specify a revision number. This determines
>>whether "svn status" and other commands are atomic at the level of
>>an individual recursive target. (The client still loops over
>>multiple explicitly-mentioned targets; that is a different issue.)
>
> Yes, it is atomic for that one operation (but not across multiple
> ones).

Good. That's what I thought and hoped.

> When we look at mod_dav_svn's parsing of that XML element, we
> see that it boils down to an atol() call. So, you better have a
> number there, even it is SVN_INVALID_REVNUM (and not the string "HEAD"
> or such).

That's fine. RA-DAV:make_reporter either puts the number in that element, or omits the element altogether if the number was SVN_INVALID_REVNUM.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 22 19:31:16 2003