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
read-only.
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