Matthias Bühler wrote on Thu, Nov 03, 2011 at 12:04:04 +0000:
> Hi,
>
> I have a problem checking out folders from a subversion repository.
>
> We're using the hudson continuous integration system to build projects that
> are on a subversion server. We're currently considering to upgrade to server
> version 1.7.1, but can't get it to work together with hudson.
>
> Checkout of the repository root works fine, but as soon as I want to check
> out a subfolder (like "trunk" or "trunk/my_sub_folder"), I get an error
> message (in hudson's command line output):
>
> >>
> Checking out svn://172.16.2.156/REPO/trunk/my_sub_folder revision:
> 02-Nov-2011 16:42:29 depth:infinity ignoreExternals: false
> ERROR: Failed to check out svn://172.16.2.156/REPO/trunk/my_sub_folder
> org.tmatesoft.svn.core.SVNException: svn: URL
> 'svn://172.16.2.156/REPO/trunk/my_sub_folder' doesn't exist
> <<
>
> A look at the server log file hints that there is a problem resolving the
> subfolder path: it seems to repeat the path, resulting in
> "/trunk/my_sub_folder/trunk/my_sub_folder".
>
> Log file from subversion server 1.7.1 (the checkout fails):
> >>
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO open 2
> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops)
> /trunk/my_sub_folder - -
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-latest-rev
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-dated-rev
> 2011-11-03T10:34:22.201000Z
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-dated-rev
> 2011-11-03T10:34:22.201000Z
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO check-path
> /trunk/my_sub_folder/trunk/my_sub_folder@3
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO stat
> /trunk/my_sub_folder@3
> <<
>
> Log file from subversion server 1.6.17 (the checkout works):
> >>
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO open 2
> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops)
> /trunk/my_sub_folder - -
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-latest-rev
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-dated-rev
> 2011-11-02T15:45:23.000000Z
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-dated-rev
> 2011-11-02T15:45:23.000000Z
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO check-path
> /trunk/my_sub_folder@3
This is where this log differs from the previous one. Perhaps you could
get a wire trace (wireshark, tcpdump, etc) and diff the protocol traces
until this point to see what leads to the divergence?
> 2704 2011-11-02T15:45:23.655483Z 172.16.2.108 - REPO get-dated-rev
> 2011-11-02T15:45:23.000000Z
> 2704 2011-11-02T15:45:23.666498Z 172.16.2.108 - REPO checkout-or-export
> /trunk/my_sub_folder r3 depth=infinity
> 2704 2011-11-02T15:45:24.845189Z 172.16.2.108 - REPO stat /@3
> <<
>
> Using the command-line client 1.7.1, I can check out the same folder from
> server 1.7.1 without any problem. Server log:
> >>
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO open
> 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo
> log-revprops) /trunk/my_sub_folder SVN/1.7.1 -
That's odd. With 1.7 client and server you should see the
atomic-revprops capability somewhere.
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO get-latest-rev
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO reparent
> /trunk/my_sub_folder
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO check-path
> /trunk/my_sub_folder@3
Hmm.
> 2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO open
> 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo
> log-revprops) /trunk/my_sub_folder SVN/1.7.1 -
> 2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO get-latest-rev
> 2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO checkout-or-export
> /trunk/my_sub_folder r3
> <<
>
> In the last example, I can see that the server knows the client's
> version ("SVN/1.7.1"), while in the first two examples, there is just
> a "-" instead of the version number.
>
> Is this an issue with the client failing to report its version
> properly, or is the server supposed to work even though it doesn't
> know the client's version?
>
The client can optionally report its version to the server.
> The server is running on Windows XP 32-bit, the client on Windows
> 7 64-bit. The Hudson client has the latest Hudson subversion plugin,
> which uses SVNKit 1.3.5.
Note that SVNKit doesn't use the official C libraries at all. If the
problem turns out to be client side, you'll have to take it up with
them, not us.
