[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: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-03-12 09:13:59 CET

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
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 12 09:14:27 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.