Integration with Subversion

  • Serrano

    Serrano - 2005-06-02

    I'm trying to integrate the codestriker with subversion, but without success.
    There may be some configuration issue, but I'm not sure.
    The error message when I try to create a topic which should automatically generate the diff from subversion is the following :

    [Thu Jun 2 17:57:18 2005] open3: IO::Pipe: Can't spawn-NOWAIT: No such file or directory at C:/codestriker/bin/../lib/Codestriker/Repository/ line 111

    Can you help me?


    • David Sitsky

      David Sitsky - 2005-06-02

      I take it you are running this under Windows?  I believe this is a problem which has been fixed already.

      Can you try downloading the 1.9.0.beta1 release and see if this resolves your problem?

      • Serrano

        Serrano - 2005-06-08

        Thanks for the answer.
        Yes, I'm running under Windows, using IIS as the web server.
        I have upgraded to 1.9.0.beta1 and still got the same error.
        Maybe it is some problems with parameters I'm passing when creating the topic.
        Can you give me any example creating a topic integrated with subversion?

        • Kevin R. Priest

          Kevin R. Priest - 2005-10-26

          I am using Codestriker 1.9.1 and am getting the same problem. The only differences are in the path to Codestriker and the line number:

          open3: IO::Pipe: Can't spawn-NOWAIT: No such file or directory at C:/Program Files/Codestriker/bin/../lib/Codestriker/Repository/ line 119

          Just before line 119, I added

          print STDERR $cmd;

          and checked Apache's error log. I copied out the command

          Files/Subversion/bin/svn.exe" cat --non-interactive --no-auth-cache  --revision
          HEAD "http://localhost/repos/GalaxyBuild/trunk/build.xml"

          and pasted it into a command window; the file was retrieved without problems.

          I am running Windows XP, Apache 2.0.54, perl 5.8.7, subversion 1.2.3.

    • David Sitsky

      David Sitsky - 2005-06-08

      I can see what the problem is.  This wasn't an issue on UNIX machines, as the "svn" executeable is automatically in the PATH of the webserver, but this isn't the case under windows.

      Modify the lib/Codestriker/Repository/ file, and go to lines 19, 111 and 146.

      You need to replace the "svn" in the string, with the full windows path.  Eg, on line 111 might become:

      my $cmd = "\"C:/Program Files/SVN/svn.exe\" cat --non-interactive --no-auth-cache " . $self->{userCmdLine} .

      I'll modify the codestriker.conf file for the proper release of 1.9.0, so that this will be easier.

      Can you try this and let me know if this works for you?

    • David Sitsky

      David Sitsky - 2005-06-09

      I have actually checked in code into CVS, which will allow you to specify the path to your svn.exe file.  If you have access to CVS, try checking it out and please let me know if this fixes your problem.

    • David Sitsky

      David Sitsky - 2005-06-19

      I have just released 1.9.0.beta3 which now has the $svn configuration setting in codestriker.conf.  Try downloading it, setting this value to your svn.exe executable, and try again.  Please let me know if this fixes the problem.

    • Serrano

      Serrano - 2005-06-21


      I have installed the beta3 version and still got the same error.
      I also changed to Apache Web Server (1.3), but no changes.....

      That's the error message:
      open3: IO::Pipe: Can't spawn-NOWAIT: No such file or directory at C:/codestriker-1.9.0.beta3/bin/../lib/Codestriker/Repository/ line 119

      Thanks for your support

      • David Sitsky

        David Sitsky - 2005-06-22

        Can you post your codestriker.conf file here?  This is a silly question, but I take it you set your $svn to the full path of your svn.exe file?

    • David Sitsky

      David Sitsky - 2005-10-26

      Can you apply the patch described at:

      And let me know if that fixes your problem?  Thanks.

      • Kevin R. Priest

        Kevin R. Priest - 2005-10-27

        Yes, the referenced patch did solve the problem. I noted a possible discrepancy (added as a comment to the referenced request) among the three instances of the open3() call, but it didn't affect my situation.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks