Philip Martin <philip@codematters.co.uk> writes:
> I have been experiencing network problems recently. These are nothing
> to do with subversion, however they do cause the subversion client to
> time-out. On one occasion this occurred while running 'svn up' on a
> subversion working copy. This left the subversion/bindings working
> copy in a corrupt state:
Don't throw out that working copy! :-) (Tar it up and attach it to a
new issue.)
> I am not quite sure where the problem lies but I suspect the
> .svn/entries file is corrupt. Revision 724 created the bindings/swig
> subdirectory and moved the above files into it. The suspect entries
> file contains both the new subdirectory and the files that should have
> been moved. Thus I suspect that the network connection failed during
> the processing of this part of the delta.
So the entries file has the new entries, but the actual dirs/files
didn't get created? Sounds like Subversion is doing things in the
wrong order.
> The best solution would be to have commit/rollback semantics on the
> working copy, but I don't know if this is feasible. Does cvs suffer
> from the same problem?
I think the best solution is for Subversion not to get into these
situations in the first place, though there is the "svn cleanup"
command, and some kind of local rollback might be possible too (maybe
extend the functionality of "svn revert"?).
Anyway, there is no reason the working copy should ever get into such
a state. CVS almost never does -- it's quite careful about such
things. Apparently, we weren't. :-)
Are you debugging, or should someone else start looking into it?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:54 2006