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

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

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

-- 
   Les Mikesell
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org