On Thu, 01 Dec 2005, Daniel Rall wrote:
> On Thu, 01 Dec 2005, Daniel Rall wrote:
> > On Thu, 01 Dec 2005, Mark Phippard wrote:
> > ...
> > > > On 12/1/05, Daniel Rall <email@example.com> wrote:
> > > > > > I debugged a command line session to rule out problems with JavaHL
> > > > > > and saw that status.c's change_file_prop receives this odd looking
> > > > > > name value pair:
> > > > > >
> > > > > > + name 0x00d5fac8 "svn:entry:committed-rev"
> > > > > > - value 0x0012f510
> > > > > > + data 0x00d5fa88 "/svn13X/13TR/!svn/ver/9/Dir%20A/Doc%20A.txt9"
> > > > > > len 0x0000002c
> > > > > "data" looks like it's pointing to a mod_dav_svn URI which has been
> > > > > URL-encoded, but the "9" at the end of the string looks especially
> > > > > suspicious. Memory management problem?
> > We've got some leftover cruft before the 9. We need to
> > determine whether the server is responding with that (or something
> > else invalid), or whether the client is mishandling the server's
> > response.
> The latter is seeming more and more likely, unless this area is
> already significantly different between trunk and 1.3.
And indeed, that was the problem (also reproducible in trunk). I've
committed the following fix to libsvn_ra_dav:
--- subversion/libsvn_ra_dav/fetch.c (revision 17588)
+++ subversion/libsvn_ra_dav/fetch.c (revision 17589)
@@ -2747,14 +2747,15 @@
+ if (rb->fetch_content)
+ /* record the href that we just found */
+ svn_ra_dav__copy_href(rb->href, rb->cdata_accum->data);
/* do nothing if we aren't fetching content. */
- /* record the href that we just found */
- svn_ra_dav__copy_href(rb->href, rb->cdata_accum->data);
/* if we're within a <resource> tag, then just call the generic
RA set_wcprop_callback directly; no need to use the
I've proposed this non-destabilizing change for backport to 1.3. (It
will not require a restart of the soak.)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Dec 1 22:53:02 2005