Bert Huijben wrote on Wed, Apr 18, 2012 at 15:08:41 +0200:
> > -----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.
>
FTR, this is r1327474 and its follow-ups, which will be merged to 1.7.5 tomorrow.
Received on 2012-04-25 12:33:39 CEST