Les Mikesell wrote:
> 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...
If you were executing some sort of update or other command, how is the
user supposed to commit? I don't want people committing every useless
modification either. In many cases, recovering from a borked wc is
mostly annoying. The problem isn't always a matter of whether to commit
frequently.
One thing Subversion doesn't handle well is if you have a set of files
which are generated by an external program. Sometimes these files or
directories will get overwritten rather than just updated. This kills
the .svn dir and then you have a problem.
>> 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.
>
I wouldn't call it crash-prone. However, if there is an error during
the processing of a command, the working-copy often goes to purgatory or
something resembling it. Sometimes it can be recovered, sometimes not.
>> 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?
There's a big discussion on the dev list regarding the .svn directories
and moving them out of the working copy. This would be a big help. I
think that doing this would be a great option.
---------------------------------------------------------------------
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:38:29 2007