[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-12 09:34:42 CET

On 3/12/07, Les Mikesell <lesmikesell@gmail.com> 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. 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.

And it did so by sending *all* local files to the server. You have to
make trade-offs somewhere...

> > 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 meant no damaged data ended up in the repository.



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