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

Re: ra_dav mass-commit status

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-08-25 02:26:26 CEST

On Fri, Aug 24, 2001 at 07:02:16PM -0500, cmpilato@collab.net wrote:
> Greg Stein <gstein@lyra.org> writes:
> > 948 successful commits
> > 41 svndiff failures(?) (yes, Mike's patch is in there)
> > 11 failures to lock WC (due to existing locks)
> > ----
> > 1000 attempted commits
>
> Dangit. Friggin' svndiff.
>
> > * produce a short recipe for repro'ing the svndiff failure (and pass this to
> > cmpilato for investigation)
>
> Thank you, sir.

Got the script for ya :-) [attached]

Note that the first change doesn't trigger it. It is the second. And I just
verified that using ra_local succeeds... hmm.

Probably means that it is in mod_dav_svn, or in the stream returned by
svn_txdelta_parse_svndiff(). mod_dav_svn simply creates that stream and
feeds it content from the network pipe. My earlier post with an actual
capture of those bytes seemed to indicate there was nothing wrong on the
client side (i.e. it got the right bytes out). Thus, it must be on the
server. Given that we correctly write text/plain into the FS, I would assume
that the mod_dav_svn logic for transferring bytes from the pipe is valid (we
are fed the bytes and then, in turn, feed them to the FS in one of two ways;
the branch with the svndiff parsing stream is actually the simpler of the
two (see mod_dav_svn/repos.c::dav_svn_write_stream)). That leaves me with an
initial suspicion / starting point of the svn_txdelta_parse_svndiff function
and its subcomponents.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

  • text/plain attachment: repro
Received on Sat Oct 21 14:36:37 2006

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.