[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion 1.7.1: can't checkout from hudson

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 4 Nov 2011 01:43:50 +0200

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_at_3
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO stat /trunk/my_sub_folder_at_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_at_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_at_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.
Received on 2011-11-04 00:44:42 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.