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

Re: Checksum error

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 06 May 2008 17:07:06 -0400

Martin Krischik <krischik_at_users.sourceforge.net> writes:
> First I like to quote a matra I created for myself over the years beeing a
> programmer:
>
> "Error messages without a hint on how to resolve the problem are useless and
> only frustrate the user."

I agree they frustrate the user (sorry), but they are not useless -- for
example, when you post them to a mailing list, others may recognize the
problem.

Of course, it would be great to make this error message better. Can you
think of a way? One solution would be to write a FAQ entry about this,
and then point to the URL from the error message.

> As far as I see not having checksums at all would be by far better then the
> use "deltree". Yes, .svn/text-base/org.eclipse.core.resources.prefs.svn-base
> is corrupted - but what is that compared with the actual
> org.eclipse.core.resources.prefs file.

It's important to catch corruption early and prevent commits based on
corrupt data. The primary purpose of the checksums is to prevent bad
data from getting into the repository. If they also enable you to *fix*
the problem locally, that's a bonus.

> Personally I think "svn cleanup" should fix checksum errors.

Hmmm. How? If Subversion knew for sure what data should be there, it
wouldn't error at all, it would just put the right data in place. Maybe
'svn cleanup' could contact the repository and get the file, is that
what you're thinking?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-06 23:07:29 CEST

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

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