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

Re: Has Subversion's attitude toward dataloss changed significantly since 0.27?

From: Garance A Drosihn <drosih_at_rpi.edu>
Date: 2007-03-13 03:38:41 CET

At 3:13 AM -0500 3/12/07, Les Mikesell wrote:
>Erik Huelsmann wrote:
>>>This isn't going to fix the recently posted case of accidentally
>>>letting a recursive tool make the same edit to the working copy
>>>and its supposed-to-be pristine counterpart. You probably can't
>>>fix that case short of a major change to allow the pristine copies
>>>to be offset in a parallel directory structure, but it would be
>>>nice to stop and make the problem very obvious if you notice any
>>>mtime's newer on the pristine copies than they should be - at
>>>least if you have anything to indicate what they should be.
>>Right, but we don't (have a recorded reference). Those files are
>>marked read-only for a reason. They also have a different extention
>>for a reason.

Hrm. Looking at the files under .svn/text-base, I see what you mean.
But this raises another question: How did my errant 'find' command
screw me up? Hrm. I guess I should look into that. [time passes...]

Okay, I think I see what happened. The 'find' command executed a
'sed' command, using an edit-in-place option as implemented in
FreeBSD. It looks like that option does something similar to:
     sed s/oldString/newString/ filename > filename.new
     permit filename.new like filename
     rm filename
     mv filename.new filename

The way that option does things, it will work without any errors even
when the file is read-only. (I'll have to ask about *that* on the
FreeBSD lists!) However, after doing a few experiments with this
sed-option, I see that it does NOT work if the directory itself is

How hard would it be for subversion to make all the '.svn/text-base'
directories be read-only? It would have to know to make the
directory writable when *it* needed to modify things in there, but I
assume that would not add much overhead. Would there be any downside
to making them read-only?

>> I'm sorry, but there's no way to do that *and* we can't prevent
>>every user error in the book.
>Of course there is a way to do it. CVS wouldn't let a changed file
>go uncommitted because of some artifact in the local file system.

Well, I think Erik's change *would* have saved me from some of the
problems that I ran into while working on that repository. Maybe it
wouldn't have saved me from the mess I made with the 'find' command,
but it is an improvement and I do believe it would have saved me a
few hours of head-scratching. This is good!

>>However, the commits would have failed if the base file didn't
>>match the base in the repository, so, other than damaging the
>>administrative area, nothing went wrong there.

>What do you mean, nothing went wrong? He made a change to files
>under revision control, committed, and the changes weren't applied
>to the repository. That's about as wrong as you can get regardless
>of the reason for it.

I may have some possibly better suggestions for this issue, but I
need to do some more thinking about them. I think I also need to go
back and regenerate the problem I had, so I can be sure I know
exactly what happened.

Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 13 02:39:03 2007

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.