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

          The log said the revision after you made a new commit is 9493. When you
          committed, svn should report you the new revision. What was it? Was it 9493,
          9494, etc?

          Kohsuke Kawaguchi added a comment - The log said the revision after you made a new commit is 9493. When you committed, svn should report you the new revision. What was it? Was it 9493, 9494, etc?

          ahmetaa added a comment -

          well, i try again, after i commit from console,

          Sending lib\readme.txt
          Transmitting file data .
          Committed revision 9539.

          thisi is the console output from hudson:

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

          ahmetaa added a comment - well, i try again, after i commit from console, Sending lib\readme.txt Transmitting file data . Committed revision 9539. thisi is the console output from hudson: [server] $ svn update -q --non-interactive --username guest --password guest $ svn info --xml server Revision:9507 no change for server since the previous build

          What are the relationship between the 'server' directory that Hudson is building
          and the 'lib/readme.txt' that you committed?

          It looks like lib/readme.txt isn't in the server directory.

          Can you send me or post the job configuration (you can get it from
          $HUDSON_HOME/jobs/JOBNAME/config.xml)?

          Kohsuke Kawaguchi added a comment - What are the relationship between the 'server' directory that Hudson is building and the 'lib/readme.txt' that you committed? It looks like lib/readme.txt isn't in the server directory. Can you send me or post the job configuration (you can get it from $HUDSON_HOME/jobs/JOBNAME/config.xml)?

          ahmetaa added a comment -

          that file was in a directory which belongs the "server" project.
          server/deploy/../lib to be exact. i will attach the config to the issue shortly,
          also i will checkout the code to see if i can do stg about it.

          ahmetaa added a comment - that file was in a directory which belongs the "server" project. server/deploy/../lib to be exact. i will attach the config to the issue shortly, also i will checkout the code to see if i can do stg about it.

          ahmetaa added a comment -

          This is the config.

          <?xml version="1.0" encoding="UTF-8" ?>
          <project>
          <scm class="hudson.scm.SubversionSCM">
          <modules>http:...erased by ahmetaa.../server</modules>
          <useUpdate>true</useUpdate>
          <username>guest</username>
          <otherOptions>--password guest</otherOptions>
          </scm>
          <triggers class="vector" />
          <builders class="vector">
          <hudson.tasks.Ant>
          <targets>war-buildmachine</targets>
          <antName>(Default)</antName>
          </hudson.tasks.Ant>
          </builders>
          <publishers class="vector" />
          <canRoam>true</canRoam>
          <disabled>false</disabled>
          <description />
          <actions class="vector" />
          </project>

          ahmetaa added a comment - This is the config. <?xml version="1.0" encoding="UTF-8" ?> <project> <scm class="hudson.scm.SubversionSCM"> <modules>http:...erased by ahmetaa.../server</modules> <useUpdate>true</useUpdate> <username>guest</username> <otherOptions>--password guest</otherOptions> </scm> <triggers class="vector" /> <builders class="vector"> <hudson.tasks.Ant> <targets>war-buildmachine</targets> <antName>(Default)</antName> </hudson.tasks.Ant> </builders> <publishers class="vector" /> <canRoam>true</canRoam> <disabled>false</disabled> <description /> <actions class="vector" /> </project>

          I tried to reproduce the problem locally by creating a dummy svn module and a
          job set up.

          What puzzles me is that in svn the directory revision number is always bigger
          (or equal to) the revision numbers of files in it.

          So say when you have a module like this in svn:

          server
          +- dir1
          +- lib
          +- readme.txt

          and if you commit a new readme.txt rev.9539, then it should also create rev.9539
          for all its ancestor directories. So when Hudson runs "svn update ...", it
          should update the revision of the server directory to 9539. Yet after running
          svn update, svn reported that your server directory is still at 9507.

          What happens if you run this same "svn update -q --non-interactive --username
          guest --password guest" command at the Hudson workspace directory manually? Is
          there something strange about workspace that prevents this update? Maybe -q is
          suppressing interesting messages?

          Kohsuke Kawaguchi added a comment - I tried to reproduce the problem locally by creating a dummy svn module and a job set up. What puzzles me is that in svn the directory revision number is always bigger (or equal to) the revision numbers of files in it. So say when you have a module like this in svn: server +- dir1 +- lib +- readme.txt and if you commit a new readme.txt rev.9539, then it should also create rev.9539 for all its ancestor directories. So when Hudson runs "svn update ...", it should update the revision of the server directory to 9539. Yet after running svn update, svn reported that your server directory is still at 9507. What happens if you run this same "svn update -q --non-interactive --username guest --password guest" command at the Hudson workspace directory manually? Is there something strange about workspace that prevents this update? Maybe -q is suppressing interesting messages?

          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: