Subversion/SVN 1.7 upgrade causes CruiseControl.Net to checkout instead of update (Bug #244)

Added by Disaster Area over 5 years ago. Updated almost 5 years ago.

Status:Closed Start date:12/21/2012
Priority:Normal Due date:
Assignee:Ruben Willems % Done:


Category:- Spent time: -
Target version:1.8.4
Affected version:1.6



as described by others (see here] After an update of Subversion (in my case it was an update of VisualSVN Server) to SVN 1.7, the working copy format has changed. So you get the Error E155000. Does CC Version 1.8.2 solve this?


Updated by Ruben Willems over 5 years ago

There is a patch pending

what it does is the following : Use SVN Switch instead of Update

Updated by Ruben Willems over 5 years ago

similar to #245 and #234

Updated by Ruben Willems over 5 years ago

  • Target version set to 1.8.4

Updated by Disaster Area over 5 years ago

Are your really sure, that the code change that "eric v" pulled to github will solve the problem? "eric v" seams to be right in using "switch" instead of "update" but who says, that the SVN development team doesn't change this. I.m.h.o. it should be configurable in CC, if the svn call uses "switch" instead of "update".

But coming back to the main problem. I do not know how CC works internally but the error described in this thread is, that CC does a "CHECKOUT" !! to a folder, that already is a working copy (wc) of SVN. In my testcase, I did a fresh checkout manually and afterwards I started CC which then produced the Error E155000. It seams, that CC does not recognise, that the PATH already contains a wc. The code change in github by "eric v" only changes a parameter value "update" to "switch". So "update" should work, but it seams that CC does not call "update". It calls "checkout"!!!!

Please take a deeper look into this.

By the way: When will this changes arise in the builds. Are there intermediate nightly builds?

Must I write a workaround by using native svn commands within a Batch-File, triggerd by CC?

Updated by Ruben Willems over 5 years ago

That's also the reason I did not place it in the 1.8.3
if you look at the comments in the pull request, I did ask this to the poster.

From head about the working, CCNet checks if there is a .svn (or_svn) folder, if that does not exist,
it does a checkout

apparently this structure has been changed in SVN 1.7
how can we test this?
can I have an svn 1.6 and svn1.7 client on the same machine?
and if I set up ccnet with the different clients, will it work?
--> can a svn 1.6 client connect to a 1.7 server for example

there are nightly builds
all code comes into the 1.9 branch, and when ok and not breaking is backported to 1.8

Updated by Disaster Area over 5 years ago

Hallo Mr Willems or should I say "Hallo Ruben"?

Thanks for your reply. The dependencies between the svn client version and the svn server version are well documented at this apache subversion project site since subversion is now an apache project. There you'll find a short description about the client metadata change (only one .svn (_svn) folder at the top of the wc) and hints about compatibility between client and server version. In short:

[...]Subversion 1.7 servers use the same repository format as Subversion 1.6. Therefore, it is possible to seamlessly upgrade and downgrade between 1.6.x and 1.7.x servers without changing the format of the on-disk repositories.[...]

[...]Subversion 1.7 clients use a new working copy format. Subversion 1.7 clients cannot use Subversion 1.6 (and earlier) working copies. Existing working copies created with Subversion 1.6 and earlier need to be upgraded before they can be used with a Subversion 1.7 client (see below for details).

Subversion 1.7 maintains API/ABI compatibility with earlier releases, by only adding new functions, never removing old ones. A program written to any previous 1.x API can both compile and run using 1.7 libraries. However, a program written for 1.7 cannot necessarily compile or run against older libraries.[...]

And there are some changes in the output of the command line. Take a deeper look into the apache site. It is well documented and easy to understand.

I hope that helps.

Updated by Stefan Spieker over 5 years ago

I stumbled over the same problem, and i think you should check all parent folders if you can find a svn directory, i think something like this might work (untested):

Replace in project/core/sourcecontrol/Svn.cs:729

private bool DoesSvnDirectoryExist(IIntegrationResult result)
    bool continueLooking = true;
    while (continueLooking)
        string target = result.BaseFromWorkingDirectory(WorkingDirectory);
        string svnDirectory = Path.Combine(target, ".svn");
        string underscoreSvnDirectory = Path.Combine(target, "_svn");            
        if (fileSystem.DirectoryExists(svnDirectory) || fileSystem.DirectoryExists(underscoreSvnDirectory))
            // it is a root working directory or SVN < 1.7
            return true;
        else if (fileSystem.DirectoryExists(target))
            // take a look into parent directory
            target = Path.Combine(target, "..");
            // is parent a valid directory on disk?!
            if (!fileSystem.DirectoryExists(target))
                // since it does not exist we can stop looking
                // maybe we have also to check if it is already at root level?!
                continueLooking = false;
            continueLooking = false;
    return false;

Updated by Disaster Area over 5 years ago

Hallo Stefan,

good idea. But I think it is better to ask subversion itself, if it is a working copy folder or just a folder. Take a look at the output of "svn info".

In Version 1.7 it shows "svn: E155007: '<path_to_folder>' is not a working copy", where <path_to_folder> might be your result of "result.BaseFromWorkingDirectory(WorkingDirectory);"

If it's a working copy, "svn info"s output is like:
DOS>svn info <path_to_folder>
Path: <path_to_folder>
Working Copy Root Path: <path_to_folder>
URL: https://MySvnServer/svn/MyProjects/Project1/trunk
Repository Root: https://MySvnServer/svn/MyProjects
Repository UUID: 333bfa73-9f0c-ae47-949b-0662850e4ac7
Revision: 12071
Node Kind: directory
Schedule: normal
Last Changed Author: DisasterArea
Last Changed Rev: 12071
Last Changed Date: 2012-12-19 14:10:11 +0100 (Mi, 19 Dez 2012)

I think analysing the output of "svn info" is more robust than thinking about folders. My hope is, that svn development will not often change the output format of svn info.

@Ruben Willems: when will it be fixed? Any suggestion?

Updated by Ruben Willems almost 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Ruben Willems

Updated by Ruben Willems almost 5 years ago

  • Status changed from In Progress to Closed

Updated by Disaster Area almost 5 years ago


so I upgraded to 1.8.4. now and found it working with SVN 1.7. Thanks a lot. Fix has taken a while but better taking a while but fixed than a notworking short hotfix. Thanks a lot so far.

Also available in: Atom PDF