Bert Huijben wrote on Wed, Apr 18, 2012 at 15:08:41 +0200: > > -----Original Message----- > > From: Hyrum K Wright [mailto:hyrum.wri...@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 <pavle...@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.
