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.
bye,
Erik.
---------------------------------------------------------------------
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