Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-113

in svn update mode, hudson do not detect updates

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      although i made a new commit, the update was not available during the build. it
      gave this:

      [server] $ svn update -q --non-interactive --username guest --password guest
      $ svn info --xml server
      Revision:9493
      no change for server since the previous build

      environment:
      windows 2003,
      tomcat 5.5.17,
      hudson:1.49
      svn client: 1.3.0

          [JENKINS-113] in svn update mode, hudson do not detect updates

          ahmetaa added a comment -

          yes, i was puzzled too because even now when i run

          svn info --xml server

          from the hudson workspace, it gives me this result:
          ----------------------------------------
          <?xml version="1.0" encoding="utf-8"?>
          <info>
          <entry
          kind="dir"
          path="server"
          revision="9507">
          <url>http://--erased--/trunk/server</url>
          <repository>
          <root>http://--erased--/projects</root>
          <uuid>75bc6971-29f9-0310-ad29-836d730da295</uuid>
          </repository>
          <wc-info>
          <schedule>normal</schedule>
          </wc-info>
          <commit
          revision="9507">
          <author>-erased-</author>
          <date>2006-09-08T19:26:46.234603Z</date>
          </commit>
          </entry>
          </info>
          ---------------------------

          i suspect that i know something fundamentally wrong about svn then.
          seems like when you run the "svn info --xml server" command it is only bringing
          the latest revision of the "current" working directory, not the latest revision
          of the project. because if i do it like this:

          svn info --xml http://--erased--/trunk/server

          <?xml version="1.0" encoding="utf-8"?>
          <info>
          <entry
          kind="dir"
          path="server"
          revision="9546">
          <url>http://--erased--/trunk/server</url>
          <repository>
          <root>http://--erased--/projects</root>
          <uuid>75bc6971-29f9-0310-ad29-836d730da295</uuid>
          </repository>
          <commit
          revision="9546">
          <author>-erased-</author>
          <date>2006-09-09T01:48:31.618907Z</date>
          </commit>
          </entry>
          </info>

          so basically the info command should be run using the repository url, not
          working directory.

          ahmetaa added a comment - yes, i was puzzled too because even now when i run svn info --xml server from the hudson workspace, it gives me this result: ---------------------------------------- <?xml version="1.0" encoding="utf-8"?> <info> <entry kind="dir" path="server" revision="9507"> <url> http://--erased--/trunk/server </url> <repository> <root> http://--erased--/projects </root> <uuid>75bc6971-29f9-0310-ad29-836d730da295</uuid> </repository> <wc-info> <schedule>normal</schedule> </wc-info> <commit revision="9507"> <author>- erased -</author> <date>2006-09-08T19:26:46.234603Z</date> </commit> </entry> </info> --------------------------- i suspect that i know something fundamentally wrong about svn then. seems like when you run the "svn info --xml server" command it is only bringing the latest revision of the "current" working directory, not the latest revision of the project. because if i do it like this: svn info --xml http://--erased--/trunk/server <?xml version="1.0" encoding="utf-8"?> <info> <entry kind="dir" path="server" revision="9546"> <url> http://--erased--/trunk/server </url> <repository> <root> http://--erased--/projects </root> <uuid>75bc6971-29f9-0310-ad29-836d730da295</uuid> </repository> <commit revision="9546"> <author>- erased -</author> <date>2006-09-09T01:48:31.618907Z</date> </commit> </entry> </info> so basically the info command should be run using the repository url, not working directory.

          But right before Hudson runs "svn info --xml server", it runs "svn update" in
          the server directory (which is what "[server]" prefix means), so it surely
          brought the latest rev.9546 to the local workspace?

          Can you run the same "svn update" command that Hudson runs, but without -q
          option? I suspect for some reasons "svn update" is not bringing over the latest
          revision.

          Kohsuke Kawaguchi added a comment - But right before Hudson runs "svn info --xml server", it runs "svn update" in the server directory (which is what " [server] " prefix means), so it surely brought the latest rev.9546 to the local workspace? Can you run the same "svn update" command that Hudson runs, but without -q option? I suspect for some reasons "svn update" is not bringing over the latest revision.

          ahmetaa added a comment -

          if i go to the Hudson_home/...server/workspace/ and run the "svn update (witohut
          -q)" from console it brings the updates correctly. However, even hudson make the
          update call before calling the "svn info" when i trigger the build, i dont see
          the updates in the workspace that i comitted. maybe i am doing something very
          wrong from the beginning.. is your test working as expected in update mode?

          ahmetaa added a comment - if i go to the Hudson_home/...server/workspace/ and run the "svn update (witohut -q)" from console it brings the updates correctly. However, even hudson make the update call before calling the "svn info" when i trigger the build, i dont see the updates in the workspace that i comitted. maybe i am doing something very wrong from the beginning.. is your test working as expected in update mode?

          If you have checked out a workspace, perhaps you might try removing that "-q"
          from Hudson's SubversionSCM.java. Maybe it's showing some warning or something.
          (But Hudson checks the svn exit code, so I'd imagine if there's something wrong,
          it will tell you so.)

          And yes, when I run this test on my system (with the server on localhost), it
          works too. Another possibility you might check is if there's any clock
          difference between the svn server and the Hudson machine (not the time zone
          difference, the clock skew.) If Hudson couldn't update the workspace but you
          were able to do so manually later, then clock sounds like a possibility.

          Kohsuke Kawaguchi added a comment - If you have checked out a workspace, perhaps you might try removing that "-q" from Hudson's SubversionSCM.java. Maybe it's showing some warning or something. (But Hudson checks the svn exit code, so I'd imagine if there's something wrong, it will tell you so.) And yes, when I run this test on my system (with the server on localhost), it works too. Another possibility you might check is if there's any clock difference between the svn server and the Hudson machine (not the time zone difference, the clock skew.) If Hudson couldn't update the workspace but you were able to do so manually later, then clock sounds like a possibility.

          ahmetaa added a comment -

          sorry koshuke, but we are in crunch time, i cannot test any further the issue
          for some days. However, i did change the svn server's time (make it 1 minute
          further then the build server) but still same behavior. for now we will go with
          not using update, after all it works that way. this seems like an issue with our
          usage or environment, so feel free to resolve the issue as cannot reproduce or
          something. it would be nice if some other person tests this too.

          ahmetaa added a comment - sorry koshuke, but we are in crunch time, i cannot test any further the issue for some days. However, i did change the svn server's time (make it 1 minute further then the build server) but still same behavior. for now we will go with not using update, after all it works that way. this seems like an issue with our usage or environment, so feel free to resolve the issue as cannot reproduce or something. it would be nice if some other person tests this too.

          Thanks. I'm sorry that we couldn't fix the problem.

          I'll keep it open for a while to see if someone else will have the same problem.
          If not, I'll close it as not reproducible.

          Kohsuke Kawaguchi added a comment - Thanks. I'm sorry that we couldn't fix the problem. I'll keep it open for a while to see if someone else will have the same problem. If not, I'll close it as not reproducible.

          issue #167 which seems to be related to this.

          Kohsuke Kawaguchi added a comment - issue #167 which seems to be related to this.

          pnico added a comment -

          I'm seeing this happen on every build on two different Windows machines.

          pnico added a comment - I'm seeing this happen on every build on two different Windows machines.

          Starting 1.74, Hudson uses Java subversion implementation, and hopefully we
          won't see strange problems like this.

          Kohsuke Kawaguchi added a comment - Starting 1.74, Hudson uses Java subversion implementation, and hopefully we won't see strange problems like this.

          Marking as closed, unless the problem reappears after 1.74.

          Kohsuke Kawaguchi added a comment - Marking as closed, unless the problem reappears after 1.74.

            Unassigned Unassigned
            ahmetaa ahmetaa
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: