On 12/1/05, Daniel Rall <dlr@collab.net> wrote:
> On Thu, 01 Dec 2005, Paul Burba wrote:
>
> > Mark found a problem while working with JavaHL and the status -u
> > enhancements backported to 1.3.x in r16543.
> >
> > It seems that when a WC item is out of date, the ood_last_cmt_rev is
> > always 0 if the WC is accessed via dav. Access via file:// and svn://
> > work correctly.
> >
> > 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
> >
> > The "9" is the correct commited-rev, but how it comes to be appended to
> > that path is a mystery. I'm still trying to figure out what's going on,
> > but I'm not making much progress and am in a lot of unfamiliar code...so
> > I'm putting out a plea for help! If anyone has a moment could they try to
> > duplicate this problem? And any insight into the cause is appreciated.
>
> "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?
>
> Paul, what repository resource were you trying to access with this
> 'svn status -u' invocation? It _looks_ like
> "/svn13X/13TR/!svn/ver/9/Dir A/Doc A.txt", but it would be helpful to
> get confirmation on that.
Note that (unless I'm doing my hex->decimal conversion wrong, or I
counted wrong) the length is actually correct for that data value, so
I'd lean more towards an off by one someplace than memory
corruption...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 1 20:45:57 2005