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

Re: [BUGREPORT] Problems with diff, maybe related to i18n

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-06-08 15:06:49 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> anders@gnulinux.dk writes:
>
> > For the record our repository is located here:
> > http://www.gnulinux.dk/svn/gentoo-doc-dk.
> >
> > We checked our source-code in and began to play with the different svn
> > options. svn diff -r x:y segmentation faults on our archive, it displays
> > the diff but then segfaults right before it quits.
>
> Yup, this is perfectly reproducible with any remote client. Just run
>
> svn diff -r3:4 http://www.gnulinux.dk/svn/gentoo-doc-dk
>
> And you get the segfault. I'm gdb'ing it now.
>
> For some reason, libsvn_ra_dav/fetch.c is trying to store a
> vsn-rsc-url when there is no working copy!

Okay, I think I know what the bug is.

'svn diff' uses the standard update REPORT request, so it can parse
the server response and knows what files to fetch & diff.

I recently fixed a bug with 'svn switch' so that the REPORT-response
would have an extra "resource walk" at the end, for updating
vsn-rsc-urls.

If you run 'svn diff' against svn.collab.net, which is running an old
version of mod_dav_svn, it doesn't send the extra vsn-rsc-url walk;
but if you run it against Anders' repository, we're definitely getting
the extra data in the repsonse.

I've got to run out now... but the solution is in the case of 'svn
diff', either (1) ra_dav must tell mod_dav_svn not to do the extra
resource-walk, or (2) ra_dav must deliberately ignore it. I can't
remember the mechanics, I'd have to look at the code again. If it
isn't fixed when I get back later today, I can do it myself.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 8 15:08:36 2002

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