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

Re: svn commit: r1182904 - /subversion/trunk/subversion/libsvn_wc/entries.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 13 Oct 2011 18:12:58 +0200

On Thu, Oct 13, 2011 at 10:33:30AM -0500, Hyrum K Wright wrote:
> On Thu, Oct 13, 2011 at 10:25 AM, <stsp_at_apache.org> wrote:
> > Author: stsp
> > Date: Thu Oct 13 15:25:16 2011
> > New Revision: 1182904
> >
> > URL: http://svn.apache.org/viewvc?rev=1182904&view=rev
> > Log:
> > * subversion/libsvn_wc/entries.c
> >  (write_entry): If a bad base MD5 checksum is found, return a proper error
> >   message instead of asserting. Since 1.7.0 was released an overwhelming
> >   amount of TortoiseSVN users keep reporting this assertion on users@.
> >   TortoiseSVN asks users to send reports about assertions, but doesn't do
> >   so for normal errors.
>
> So the implication here is that we're just trying to hide this error
> from ourselves?
>

Not at all.

The problem is that a base text in a 1.6 working copy somehow changed
its MD5. There are various ways this can happen. There are also various
ways to deal with the problem.

One is to just assert(), which is what 1.7.0 does.
This is the worst option in my opinion.

Another is to send an error that points people at the bad file.
That is what this commit is doing.

Maybe it is also possible to make the upgrade code handle this condition
gracefully and make the upgrade succeed. However, as a quick fix I
prefer to print an error which points out the bad file. This is a very
safe change we can easily backport to improve the status quo. Any
additional enhancements to the upgrade code can come later but shouldn't
block a change which improves the error message.

Does this make sense?
Received on 2011-10-13 18:13:35 CEST

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