> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum.wright_at_wandisco.com]
> Sent: woensdag 18 april 2012 2:16
> To: Dmitry Pavlenko
> Cc: Subversion Development
> Subject: Re: svn_client_status5: ood_changed_rev is different for "http" and
> "file" protocols
>
> 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.
I just implemented the communication of this revision argument on trunk and I will propose these fixes for backport for 1.7 as it is a fully backwards compatible change.
There is just one problem with this: you can never trust an existing repository to really send this value to you. Many repositories will start sending it when upgrading to 1.8, but you can always find some public Subversion 1.0 or 1.1 repository which won't send it. (The same thing applies for the checksum values of the editor).
Maybe the status handling could detect this case and just report the HEAD (or really the internal status against) revision. But then: status won't report an author and time of the delete either.
Bert
Received on 2012-04-18 15:09:23 CEST