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

Re: svn_client_status5: ood_changed_rev is different for "http" and "file" protocols

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Tue, 17 Apr 2012 19:16:28 -0500

On Tue, Apr 17, 2012 at 4:34 PM, Dmitry Pavlenko <pavlenko_at_tmatesoft.com> wrote:
> Hello all!
>
> I have a question about internal SVN status API (trunk, r1302023).
>
> I have a repository with 2 reivsions: in r1 a "file" is added, in r2 it is deleted.
> I checkout revision 1 using
>  * file protocol and
>  * http protocol
> as a working copy and run "svn_client_status5" on a file with the following callback:
>
> svn_error_t* print_status(void *baton, const char *path, const svn_client_status_t *status,
> apr_pool_t *pool) {
>   printf("%s: revision %d\n", path, status->ood_changed_rev);
> }
>
> When I run it over file protocol, I see the following output
>
> file: revision 2
>
> but if I run over http, I see
>
> file: revision -1
>
> So the question is: if this behaviour is expected (I expected some protocol-independency)?
>
> While some debugging I've discovered that for http case "delete_entry" of the status editor is
> called with -1 revision (but with 2 for file protocol). As I understand it may be a restriction of
> http protocol but maybe SVN should perform additional requests to get missing information.

This is a restriction of the http protocol, and possibly the svnserve
protocol as well. The documentation for delete_entry() in svn_delta.h
states that "the revision parameter is typically used only for
client->server commit-type operations, allowing the server to verify
that it is deleting what the client thinks it should be deleting."

While the repository layer does return this information in the
corresponding status API, it is not marshalled over the wire for http.
 I ran into the same problem when implementing the Ev1<->Ev2 shims,
though I don't recall what the workaround was.

-Hyrum

> I've attached the repository and minimal C program that reproduces the problem. It should be run
> from within the working copy.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-18 02:17:01 CEST

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.