I use svnsync -- 1.5.5 up until recently, now 1.6.0, both from FreeBSD ports
which use gcc 3.4.6 -- on FreeBSD 6.2 to mirror the KDE SVN repository. Other
KDE SVN mirrors use svnsync on Linux, I'm not sure what versions. I use https
access to the main repository, I don't know what the other mirrors use. There
is no direct anonymous or svn:// style access to the main repository. I don't
know which version of svn the main server runs (is there a simple way to find
out?).
All of our svnsync mirroring fails on revision 951943. You can see the
revision with websvn at
http://websvn.kde.org/?pathrev=951943
and get the log with
http://websvn.kde.org/branches/?view=log&pathrev=951943
(well, assuming websvn likes that at all; i seems to take forever for me and
then 500s).
Unfortunately, getting the anonsvn service up and running again was of higher
priority than keeping a good forensic copy. I should have thought of
filesystem snapshots, I know. I worked around the problem by rsyncing a new
copy of the repo up to the problem revision + 1, then adjusting the svnsync
properties by hand, then letting svnsync go again. This seems to fix the
problem.
In order to re-create the problem (presumably, and for debugging purposes) I'm
doing yet another svnsync from r.0, but you can understand that that takes a
while with 900k+ revisions (as in nearly all day today for the first 30k, but
that's on a loaded local disk).
r.951943 changes a (long) property as part of a svk merge; it changes no files
and seems to touch only one directory:
r951943 | winterz | 2009-04-10 18:28:49 +0200 (Fri, 10 Apr 2009) | 8 lines
Changed paths:
M /branches/kdepim/enterprise4/kdepim
Blocked revisions 951934 via svnmerge
From my notes, the error message was:
svnsync: Got unexpected element svn::close-directory
This comes from libsvn_ra_neon/replay.c (I was looking at the svnsync program
from subversion 1.5.5), in start_element(). There's a comment there in the
source that says that entities are not nested. The KDE SVN server sends
(again, notes):
open-root
target-revision
open-directory
open-directory
open-directory
change-dir-prop
close-directory
close-directory
I tried futzing around with start_element(), for instance allowing
parent_state == ELEM_change_dir_prop (which is what parent_state is after the
change-dir-prop). That doesn't seem to help; after a bit of fiddling around I
had svnsync ignoring the trailing close-directory elements, but it would then
print REPORT of https://svn.kde.org/home/kde 200 OK -- and not sync. I didn't
mess around with end_element() though, so I don't know what any of the
functions called from there (e.g. change_dir_prop) were doing.
The regular svn client has no issues updating from r.951942 to 951943; only
svnsync hits a problem.
Does this seem familiar to anyone? None of the svnsync bugs that have been
files seem to apply, and searching for the specific error message didn't turn
up anything (now it shows my blog entry describing how I worked around the
problem). I can provide the revs/ and revprops/ files for some of the
revisions around the problem one, if that would help anyone. It'll be a while
before I've re-created the problem situation, though -- running svnsync for
the whole repo and for only the problem branch, to see if that makes any
difference.
[ade] (please CC, as I'm not subscribed)
Received on 2009-04-16 02:29:44 CEST