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...
The value of that tradeoff really depends on how much it is worth to
save sending a bit of data to the server. If you have decent bandwidth
or you are on the same LAN with the server it's probably not enough of a
saving to make it worth the risk of losing your changes when you do a
recursive edit (which seems like a moderately likely thing to happen,
given the location of the pristine copies). Perhaps some future
version could have an option to do a sanity check of the .svn against
the server for people who would prefer a different trade-off. Or
better yet, do the bandwidth savings through an rsync-like transfer
along the lines of backuppc which has its own rsync-in-perl that works
against a compressed copy locally with a stock rsync at the other end,
or rdiff-backup which transfers the differences and stores them in a way
that can reconstruct the older versions. Something like that might even
eliminate the need for the pristine copies for people who don't care
about offline operations.
>> > 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.
I'd call it damaged if what is in the repository doesn't match what was
in the committed workspace and you didn't get an error - even if the
commit log says you didn't really commit anything.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 12 18:28:12 2007