Steve Bakke wrote:
>>> I've been in situations where subversion has gotten confused with an
>>> added folder, and the end solution was to delete the entire working tree
>>> and checkout again, with a fair amount of copying local files to and
>>> from a temporary directory.
>> If you had committed your work after every each change worth saving, a
>> fresh checkout would be an easy solution, not just for you, but for
>> anyone else working on the code, or to let you pick it up on a different
>> machine. If you have a 'clean trunk' policy where someone is bothered by
>> work in progress there, copy to a branch for the intermediate work and
>> merge it back when appropriate. The point of a revision control system
>> is that you put your revisions in there.
>
> That's a poor excuse for what are bugs in the client working copy code.
Perhaps, but there's no excuse for not committing your work...
> Admittedly, I haven't managed to nail down a specific issue, but I've had
> similar problems in the past. You can't just dismiss it by saying "just
> commit more often". That's like telling somebody with a crash-prone tool to
> hit save early and often. Yes, it may help prevent data loss, but it
> doesn't really solve the problem.
I haven't found svn to be crash-prone, but there are any number of
things that can go wrong with data. Having a copy in the repository
protects against all of them. There's nothing svn can or should do to
prevent you from removing or otherwise trashing your own copies of files.
> Subversion working copies seem a bit
> fragile to me. I think that some of this may be due to the fact that while
> operations on the repository are atomic, operations on your working copy are
> not. As a result, your WC can get into weird intermediate states.
Filename conflicts? OS-level copies/moves/deletes instead of svn
managed commands?
--
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 Tue Feb 6 19:16:50 2007