What command can I use to access that repository with the svn client?
% svn log --non-interactive --trust-server-cert --username guest --password guest https://svn.kde.org/home/kde -r951943 2>&1 | grep -v "traced call"
..\..\..\subversion\svn\log-cmd.c:593: (apr_err=170001)
..\..\..\subversion\libsvn_client\log.c:515: (apr_err=170001)
..\..\..\subversion\libsvn_client\ra.c:449: (apr_err=170001)
..\..\..\subversion\libsvn_ra\ra_loader.c:481: (apr_err=170001)
..\..\..\subversion\libsvn_ra_neon\util.c:608: (apr_err=170001)
svn: OPTIONS of 'https://svn.kde.org/home/kde': authorization failed: Could not authenticate to server: rejected Basic challenge (https://svn.kde.org)
Daniel
(looks like I'll add an alias to the "2>&1 | grep -v traced\ call" bit...)
Adriaan de Groot wrote on Wed, 15 Apr 2009 at 23:32 +0200:
> 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)
>
>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1745697
Received on 2009-04-16 13:40:11 CEST