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

Hudson detects Subversion changes incorrectly

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

      It seems that Hudson uses the repository Revision to detect whether there were
      any changes or not, but this is not right in case when the main-line sources are
      only in some subdirectory, like

      svn://server/project/trunk
      (which is a very common practice, recommended by the Subversion team)

      Let's say that we have two subdirs in the repository:
      trunk (with main line of sources) and branches (with private sources,
      not relevant to the main line).

      Every time somebody commits (putbacks) changes into repository,
      it's Revision is incremented. Now, if somebody commits to completely
      irrelevant directory (such as branches), the revision of the
      repository is incremented, and "svn info svn://server/project/trunk" shows that
      Revision: was incremented
      Last Changed Rev: was not incremented

      So, if somebody uses Revision to detect changes, he/she would think that
      there were changes in the product sources, while in fact,
      there were no changes to the product, but only to private branches
      that do not affect the product at all.

      So, usage of repository's Revision may trigger the build while
      there were no changes to the main product sources.

      And, in fact, I see this behavior with my builds. Every time I change anything
      in my private branch, Hudson builds the project from trunk, while nothing really
      changed in trunk.

      Hudson should look an the Last Changed Rev for particular directory, specified
      in subversion URL, not for the Revision of entire workspace.

          [JENKINS-96] Hudson detects Subversion changes incorrectly

          Thanks. I just fixed it.
          If you can try the snapshot build to see if it fixes the problem, that would be
          great.

          Kohsuke Kawaguchi added a comment - Thanks. I just fixed it. If you can try the snapshot build to see if it fixes the problem, that would be great.

          vsizikov added a comment -

          AAAAAARRRRRGHHHHH!

          I deployed snapshot version of hudson.war via Tomcat's Deploy app interface,
          and ALL my settings, all my projects, all my results, EVERYTHING is gone.....

          It will take time before I could create all my projects from scratch, not to
          mention that test statisticts are gone forever...

          vsizikov added a comment - AAAAAARRRRRGHHHHH! I deployed snapshot version of hudson.war via Tomcat's Deploy app interface, and ALL my settings, all my projects, all my results, EVERYTHING is gone..... It will take time before I could create all my projects from scratch, not to mention that test statisticts are gone forever...

          vsizikov added a comment -

          OK, I've recreated one of my projects and can verify that commits to non-project
          related parts of the same subversion repository do not trigger new builds anymore.

          Thanks!

          vsizikov added a comment - OK, I've recreated one of my projects and can verify that commits to non-project related parts of the same subversion repository do not trigger new builds anymore. Thanks!

          Sorry that you lost your workspace. The upgrade section in the top page says
          "When your HUDSON_HOME points to the exploded web appliation directory, be sure
          to save them as some web containers delete them all when you redeploy a new
          application. It's generally better to set HUDSON_HOME to be outside the container."

          But of course I'm at fault by choosing such a poor default. I modified the code
          to choose ~/.hudson as the default workspace, so that should make the workspace
          safer.

          Kohsuke Kawaguchi added a comment - Sorry that you lost your workspace. The upgrade section in the top page says "When your HUDSON_HOME points to the exploded web appliation directory, be sure to save them as some web containers delete them all when you redeploy a new application. It's generally better to set HUDSON_HOME to be outside the container." But of course I'm at fault by choosing such a poor default. I modified the code to choose ~/.hudson as the default workspace, so that should make the workspace safer.

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

              Created:
              Updated:
              Resolved: