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

Re: general comments on even more permissions issues

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-14 18:09:53 CET

cmpilato@collab.net writes:
> Well, actually, this has happened at least a couple of times to Karl,
> if memory serves correctly.

Not just to me; yes, odd circumstances pop up and .svn/ areas get
corrupted from time to time.

> My proposed solution would be to get rid of that permission mangling
> crap, and go for storing MD5 checksums of the text-base (and
> prop-base?) in the entries files. If someone accidentally edits those
> things, Subversion can say, "You. Yeah, the moron who isn't paying
> attention to what he's editing. Get outta here."

+1 on the checksums no matter what we decide about read-only.

If we use MD5 checksums, not only can we detect when a file's textbase
has gone bad, we can even automatically fall back to ra->get_file() to
restore it from the repository (& something similar for prop bases).

I must confess, I still think the read-only protection a Good Thing.
Checksums can protect us from some kinds of corruption (but not all --
it only protects text and prop bases, not metadata), but recovery from
that corruption can still be expensive, and downright impossible if
one doesn't happen to have repos connectivity at the moment.

IMHO, if you're hand-editing your .svn area, you know how to turn
files read-write and back. Having to type "rm -rf" instead of "rm -r"
occasionally is a minor inconvenience, but one will habituate to it,
whereas one can't habituate to unpredictable corruptions and
recoveries.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:07 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.