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

Re: PATCH: "revision" parameter to svn_client_status

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-09-22 18:12:47 CEST

kfogel@collab.net wrote:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
>>Yes, this is exactly how it works. There's no such thing as a "moving
>>HEAD". The client says, 'what is HEAD'? The server responds, "it is
>>7111". The client then requests an update to exactly r7111. Of
>>course, by that time, 7112 might exist, but that's just too bad.
>
> Hmmm, but if I understand Julian's change correctly, that extra round
> trip is no longer happening -- the client isn't requesting a revision
> number, but instead omitting it, because the server will default to
> HEAD. If that's the case, then when multiple connections are used for
> a single status operation, the result may not be atomic.
>
> (Julian, am I understanding things right?)

Well, ... Oh, the deeper we dig ...

My patch hasn't changed the combined behaviour of

  subversion/clients/cmdline/status-cmd.c (svn_cl__status)
+
  subversion/libsvn_client/status.c (svn_client_status)

because it just moved the "omit the round trip" logic from the former into the latter. The client was already taking advantage of knowledge that the server will default to HEAD if not given a revision number.

The patch has changed the interface to svn_client_status, only in that if any caller requests "HEAD", that meaning will now be passed directly to the server (by omitting the "<S:target-revision>" field) rather than being converted first to a revision number and requesting that revision number.

But I don't think that interface change affects any part of Subversion currently, because no other caller of svn_client_status currently uses that "revision" parameter, except a recursive call via svn_client__do_external_status. (If an "external" specifies HEAD, and the underlying function "make_reporter" is not atomic, then the behaviour may have changed.)

Atomicity at this level thus depends only on the underlying behaviour of

  subversion/libsvn_ra_dav/fetch.c (make_reporter)

which is called through *do_update, *do_status, *do_switch and *do_diff.

It appears to me that this make_reporter generates a single request, not multiple requests, to the server, and if that is the case, atomicity depends only on the behaviour of the server. I haven't followed this through to the server.

On the other hand, the "file://" make_reporter in libsvn_ra_local, if given SVN_INVALID_REVNUM, first converts it into the number corresponding to HEAD, guaranteeing its own atomicity.

So my two points are:

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).

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.)

- 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 18:12:42 2003

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.