Karl Fogel <kfogel@newton.ch.collab.net> writes:
> 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've still got it. How should I create such an issue - can I do it via
email or do I need to use the web interface? How do I attach a tar
file using the web interface? The tar file of the subversion/bindings
directory is 124K.
>
> > 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.
I believe I was updating from revision 721 to revision 727. Playing
with the corrupt working copy I see
$ svn st -vn svn-broke/subversion/bindings/
_ 721 svn-broke/subversion/bindings
_ 721 svn-broke/subversion/bindings/README
_ 721 svn-broke/subversion/bindings/apr.i
_ 721 svn-broke/subversion/bindings/svn_client.i
_ 721 svn-broke/subversion/bindings/svn_delta.i
_ 721 svn-broke/subversion/bindings/svn_fs.i
_ 721 svn-broke/subversion/bindings/svn_ra.i
_ 721 svn-broke/subversion/bindings/svn_repos.i
_ 721 svn-broke/subversion/bindings/svn_string.i
_ 721 svn-broke/subversion/bindings/svn_types.i
_ 721 svn-broke/subversion/bindings/svn_wc.i
_ 721 svn-broke/subversion/bindings/util.i
$ svn st -vn svn-broke/subversion/bindings/swig
_ 0 svn-broke/subversion/bindings/swig
_ 727 svn-broke/subversion/bindings/swig/setup.py
_ 727 svn-broke/subversion/bindings/swig/svn_delta.i
_ 727 svn-broke/subversion/bindings/swig/svn_fs.i
_ 727 svn-broke/subversion/bindings/swig/svn_ra.i
_ 727 svn-broke/subversion/bindings/swig/svn_repos.i
_ 727 svn-broke/subversion/bindings/swig/svn_string.i
_ 727 svn-broke/subversion/bindings/swig/svn_types.i
_ 727 svn-broke/subversion/bindings/swig/svn_wc.i
_ 727 svn-broke/subversion/bindings/swig/util.i
$ diff -r --brief svn-broke/subversion/bindings/swig/ svn/subversion/bindings/swig/
Files svn-broke/subversion/bindings/swig/.svn/entries and svn/subversion/bindings/swig/.svn/entries differ
Only in svn/subversion/bindings/swig/.svn/text-base: README.svn-base
Only in svn/subversion/bindings/swig/.svn/text-base: apr.i.svn-base
Only in svn/subversion/bindings/swig/.svn/text-base: svn_client.i.svn-base
Only in svn-broke/subversion/bindings/swig/.svn/tmp/text-base: apr.i.svn-base
Only in svn/subversion/bindings/swig/.svn/wcprops: README
Only in svn/subversion/bindings/swig/.svn/wcprops: apr.i
Only in svn/subversion/bindings/swig/.svn/wcprops: svn_client.i
Only in svn/subversion/bindings/swig/: README
Only in svn/subversion/bindings/swig/: apr.i
Only in svn/subversion/bindings/swig/: svn_client.i
$ ls -l svn-broke/subversion/bindings/swig/.svn/tmp/text-base/apr.i.svn-base
-rw-r--r-- 1 pm pm 0 Jan 2 19:30 svn-broke/subversion/bindings/swig/.svn/tmp/text-base/apr.i.svn-base
So it looks like the network failed while constructing
bindings/swig/apr.i. The bindings/.svn/entries file contains the new
directory so that add has been processed, and the old files, so those
deletes have not yet been processed. The bindings/swig/.svn/entries
file contains some of the new files, up to the point at which the
network failed. That's pretty much what the tree delta would look
like, as far as I can see it simply gets processed in the order
received.
>
> > 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?
I'm looking, don't know how far I will get...
--
Philip
---------------------------------------------------------------------
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