[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with svn status -u via http

From: Mark Phippard <markp_at_softlanding.com>
Date: 2005-12-01 20:39:04 CET

rooneg@gmail.com wrote on 12/01/2005 02:24:58 PM:

> On 12/1/05, Daniel Rall <dlr@collab.net> 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
> > >
> > > 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...

I thought what Paul was saying, I could be wrong, is that he expected the
value in data to be just the revision number, in this case 9.

I am not sure why he didn't post it, but when he showed it to me in Debug
and he could see the XML response from DAV, the line that contained this
information looked a bit different than the others. Specifically, the XML
tag for the data ended with a /> where as all of the other bits of data
just ended with >.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
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:56:38 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.