subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: subversion 1.7.1: can't checkout from hudson
Date Thu, 03 Nov 2011 23:43:50 GMT
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.

Mime
View raw message