Created attachment 302813 [details] emerge --info for completeness When using "git svn rebase" to update my doxygen repository, it continually fails at some random update (example below). This appears to be a known bug with subversion (since version 1.5) and serf (http://subversion.tigris.org/issues/show_bug.cgi?id=2932). The update runs fine with USE=webdav-neon (the default). git svn rebase Index mismatch: 082a1fab748f7d6917c9728b6f302bb4757de12d != fd87f7468aceac47aa332d12e98a876f4aad3787 rereading 8e202fbfc02ff1398e0116e925ee2c7102e561f1 D src/libdoxygen.t D src/libdoxycfg.t M qtools/Doxyfile M addon/doxywizard/inputbool.h M src/lockingptr.h M addon/doxywizard/inputstrlist.cpp M configure M src/doxygen.h M addon/doxywizard/inputstring.cpp M Makefile.in M src/filename.h M addon/doxywizard/inputstrlist.h M addon/doxmlparser/src/paramhandler.cpp M src/configoptions.h M addon/doxywizard/version.h M addon/doxmlparser/src/sectionhandler.cpp M src/marshal.cpp M addon/doxywizard/inputstring.h M addon/doxmlparser/src/paramhandler.h M src/textdocvisitor.cpp Temp file with moniker 'svn_delta' already in use at /usr/lib64/perl5/vendor_perl/5.12.4/Git.pm line 1024.
Did you start your repo with a different SVN webdav backend? You must keep the same backend consistently. Beyond that, compile SVN with debug, and ensure SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2="yes" is in your environment, and try to actually get some debug output from SVN. I'm not sure the actual upstream bug you link is the same issue, and you're not going to convince either me or upstream that, unless you show that the raw SVN output being fed to Git doesn't match between Neon & Serf. You're going to have to get a lot more debug info, or a solid way to reproduce the problem, starting from an empty directory.
I rebuilt subversion with debug, webdav-neon, and webdav-serf and testing with a clone into a new directory. If I select the neon RA module (http-library = neon in the server config file), it works fine (a clone into a new directory succeeds). If I select the serf RA module (http-library = serf in the server config file), it fails. Again cloning into a new directory. It's also MUCH slower. SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2 had no effect. I'm unsure how to get more debugging information. There is a temp file created, but there were no obvious differences between the two back ends (and it was reaped by perl anyway). Do you know how to get more out of svn or git-svn? (My google-fu seens to be failing me.) The commands I'm using are: After changing to neon: git svn clone -s https://doxygen.svn.sourceforge.net/svnroot/doxygen doxygen-neon After changing to serf: git svn clone -s https://doxygen.svn.sourceforge.net/svnroot/doxygen doxygen-serf Neither destination directory existed before cloning. An example of the temp file: # cat ~/local/tmp/svn-u5Xy8c <S:update-report xmlns:S="svn:"> <S:src-path>/svnroot/doxygen</S:src-path> <S:target-revision>22</S:target-revision> <S:update-target>trunk</S:update-target> <S:depth>infinity</S:depth> <S:entry depth="infinity" rev="21"></S:entry> </S:update-report> dev-vcs/subversion-1.7.4 was built with the following: USE="apache2 berkdb (consolekit) debug extras java kde (multilib) nls perl (policykit) python sasl vim-syntax webdav-neon webdav-serf -ctypes-python -doc -dso -gnome-keyring -ruby" # svn --version svn, version 1.7.4 (r1295709) compiled Mar 15 2012, 06:12:38 Copyright (C) 2012 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme
