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

Hudson subversion checkout causes files to appear modified if they have no revision history

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • subversion-plugin
    • None
    • Platform: All, OS: All

      Hudson subversion checkout causes files to appear modified if they have no
      revision history

      I found this issue when experimenting with the Hudson Maven Release Plugin. mvn
      release:prepare would always fail indicating that changes were detected in the
      working copy of the source. This should never happen since "Use update" is
      unchecked for the project - a clean copy should be checked out. Verified this
      by disabling "Source Code Management" for the project and using "M2 Extra Steps
      Plugin" to execute a command line checkout of the code before the build. No
      differences detected after this (but other problems using release plugin as a
      side effect of the command line checkout - so not a good workaround).

      When investigating, I determined that this was happening with all of my Hudson
      builds, but I only detected it due to the maven release failing.

      It appears that something is awry during change log generation after checkout if
      a file has no revision history but contains an "$Id:$" keyword expansion.
      Command line svn status will report there are local changes to any file that is
      a new file with no revision history (newly checked in files) if run in the
      Hudson workspace for that project.

      A svn diff on one of the files results in the following - notice the discrepancy
      of the keyword expansion "$Id:$":

      Index: RSAFileEncryptionUtil.java
      ===================================================================
      — RSAFileEncryptionUtil.java (revision 162)
      +++ RSAFileEncryptionUtil.java (working copy)
      @@ -31,7 +31,7 @@

      • A tool for securely reading and writing file content using RSA wrapped AES
        encryption
        *
      • @author BMS
      • * @version File/Rev/Date/Author of last commit: $Id:$
        + * @version File/Rev/Date/Author of last commit: $Id$
        */
        @SuppressWarnings( {"OverloadedMethodsWithSameNumberOfParameters"}

        )
        public class RSAFileEncryptionUtil

          [JENKINS-4289] Hudson subversion checkout causes files to appear modified if they have no revision history

          bsantarelli added a comment -

          Forgot to mention that this was tested on Solaris 10 and Ubuntu 9.10

          bsantarelli added a comment - Forgot to mention that this was tested on Solaris 10 and Ubuntu 9.10

          Alan Harder added a comment -

          What are the steps to reproduce this problem? I wasn't able to see it on
          macosx. I tried using svnadmin to create a repository, using svn cmdline to
          checkout and add a file with $Id$ or $Id:$ in it, and set svn:kewords property
          to include "Id", and checkin the file. Then created a Hudson job using svn
          file://.... url and "use update" not checked. I ran a couple builds and it says
          "no changes". When I look in the workspace that Hudson checked out the Id
          keyword looks properly expanded, with filename, date, revision, username..

          Alan Harder added a comment - What are the steps to reproduce this problem? I wasn't able to see it on macosx. I tried using svnadmin to create a repository, using svn cmdline to checkout and add a file with $Id$ or $Id:$ in it, and set svn:kewords property to include "Id", and checkin the file. Then created a Hudson job using svn file:// .... url and "use update" not checked. I ran a couple builds and it says "no changes". When I look in the workspace that Hudson checked out the Id keyword looks properly expanded, with filename, date, revision, username..

          bsantarelli added a comment -

          Some more details:

          Subversion server: Collabnet binaries 1.5.6 on Solaris 10 Sparc
          Subversion client: Collabnet binaries 1.5.4 on Ubuntu 9.04

          I will attach my subversion client config file. I typically check new files in
          through the IntelliJ subversion client.

          Here is what I use for my IntelliJ class header template:

          /**

          • Comment
            *
          • @author BMS
          • @version File/Rev/Date/Author of last commit: $Id:$
            */

          Please note that the files checked out by Hudson are identical to ones that I
          manually check out from the command line. The difference is something in the
          .svn directory that is being generated during the checkout that is indicating
          that the file has changes.

          bsantarelli added a comment - Some more details: Subversion server: Collabnet binaries 1.5.6 on Solaris 10 Sparc Subversion client: Collabnet binaries 1.5.4 on Ubuntu 9.04 I will attach my subversion client config file. I typically check new files in through the IntelliJ subversion client. Here is what I use for my IntelliJ class header template: /** Comment * @author BMS @version File/Rev/Date/Author of last commit: $Id:$ */ Please note that the files checked out by Hudson are identical to ones that I manually check out from the command line. The difference is something in the .svn directory that is being generated during the checkout that is indicating that the file has changes.

          bsantarelli added a comment -

          Created an attachment (id=865)
          svn client config file

          bsantarelli added a comment - Created an attachment (id=865) svn client config file

          Alan Harder added a comment -

          maybe just change your template to use $Id$ instead of $Id:$
          does that workaround the problem? doubtful we'll be able to track down and fix
          a bug that may be in svn or svnkit..

          Alan Harder added a comment - maybe just change your template to use $Id$ instead of $Id:$ does that workaround the problem? doubtful we'll be able to track down and fix a bug that may be in svn or svnkit..

          bsantarelli added a comment -

          That workaround isn't viable for us since we have thousands of files with the
          $Id:$ already in them.

          I traced through the svnkit code myself already during a file checkout and found
          the property expansion working as expected. My knowledge of the stuff that gets
          generated for inclusion in the .svn directories is non-existent, so I couldn't
          trace through to that level. I was hoping there was a svnkit expert that works
          on the Hudson subversion plugin that could

          bsantarelli added a comment - That workaround isn't viable for us since we have thousands of files with the $Id:$ already in them. I traced through the svnkit code myself already during a file checkout and found the property expansion working as expected. My knowledge of the stuff that gets generated for inclusion in the .svn directories is non-existent, so I couldn't trace through to that level. I was hoping there was a svnkit expert that works on the Hudson subversion plugin that could

          Alan Harder added a comment -

          possibly, but it's not me :-/
          If you can construct some svnkit test code to demonstrate this problem outside
          of Hudson, you can submit an issue directly to svnkit: http://svnkit.com/tracker
          This ought to find the right experts.. though something with your particular
          version of svn server and/or client is likely involved too, as I couldn't
          reproduce this problem. You might experiment and see if a svn server upgrade
          would help..

          Alan Harder added a comment - possibly, but it's not me :-/ If you can construct some svnkit test code to demonstrate this problem outside of Hudson, you can submit an issue directly to svnkit: http://svnkit.com/tracker This ought to find the right experts.. though something with your particular version of svn server and/or client is likely involved too, as I couldn't reproduce this problem. You might experiment and see if a svn server upgrade would help..

          bsantarelli added a comment -

          Thanks - was thinking of upgrading our server soon.

          Unfortunately, I have a tight deadline right now, so will have to work around
          the problem by using a script for my release rather than the Hudson plugin.
          Maybe after things settle down I can revisit and try to reproduce through a test
          case.

          Thanks for your time looking at this - much appreciated.

          bsantarelli added a comment - Thanks - was thinking of upgrading our server soon. Unfortunately, I have a tight deadline right now, so will have to work around the problem by using a script for my release rather than the Hudson plugin. Maybe after things settle down I can revisit and try to reproduce through a test case. Thanks for your time looking at this - much appreciated.

          Alan Harder added a comment -

          let us know if we can do anything more to help, or if we can close this issue..
          thanks.

          Alan Harder added a comment - let us know if we can do anything more to help, or if we can close this issue.. thanks.

          jgon added a comment - - edited

          The problem is still there. In our case some files don't even have keyword expansion but appear as modified after a checkout.
          All the files are located in the same folder.
          The files that are not marked as modified have been changed in the latest version of Subversion we use (1.6), the ones marked as modified have been created using an older version of Subversion (1.4).
          Files are not marked as modified if the checkout is done using svn command line or TortoiseSVN.
          The only difference I see is that the Hudson subversion plugin is using the SVNKit instead of a native subversion client api.
          Comparing the checkout results between a svn client checkout and Hudson's subversion plugin shows differences is in the entries file contained the .svn folder.

          jgon added a comment - - edited The problem is still there. In our case some files don't even have keyword expansion but appear as modified after a checkout. All the files are located in the same folder. The files that are not marked as modified have been changed in the latest version of Subversion we use (1.6), the ones marked as modified have been created using an older version of Subversion (1.4). Files are not marked as modified if the checkout is done using svn command line or TortoiseSVN. The only difference I see is that the Hudson subversion plugin is using the SVNKit instead of a native subversion client api. Comparing the checkout results between a svn client checkout and Hudson's subversion plugin shows differences is in the entries file contained the .svn folder.

          jgon added a comment -

          In the meantime I have setup a script to perform a svn revert in order to enable the maven release plugin to work properly, but the problem is still there.
          Looks like the Hudson svn integration does not work properly.

          jgon added a comment - In the meantime I have setup a script to perform a svn revert in order to enable the maven release plugin to work properly, but the problem is still there. Looks like the Hudson svn integration does not work properly.

          kutzi added a comment -

          Is this still reproducable with current versions of Jenkins and the subversion-plugin?

          kutzi added a comment - Is this still reproducable with current versions of Jenkins and the subversion-plugin?

          David Kocher added a comment -

          Reproducible here with 1.480.3 and Subversion Plugin 1.45.

          David Kocher added a comment - Reproducible here with 1.480.3 and Subversion Plugin 1.45.

          kutzi added a comment -

          And it's easily reproducable by using $Id:$ as SVN keywords?

          kutzi added a comment - And it's easily reproducable by using $Id:$ as SVN keywords?

          Linards L added a comment -

          If I may I have three questions:

          1. Is it still reproducable with v1.529 and svn plugin v1.50 ?
          2. Would it be fixed with svn 1.8 support introduction when svnkit will offer proper svn wc format 1.8 support?
          3. Does this affect Ant build(s) ?

          Linards L added a comment - If I may I have three questions: 1. Is it still reproducable with v1.529 and svn plugin v1.50 ? 2. Would it be fixed with svn 1.8 support introduction when svnkit will offer proper svn wc format 1.8 support? 3. Does this affect Ant build(s) ?

          David Kocher added a comment -

          Reproducible with 1.583 and Subversion Plugin 2.4.4. I can confirm it does also affect Ant builds.

          David Kocher added a comment - Reproducible with 1.583 and Subversion Plugin 2.4.4. I can confirm it does also affect Ant builds.

          Daniel Beck added a comment -

          David: What about $Id$ vs. $Id:$ ? Does that make any difference?

          Daniel Beck added a comment - David: What about $Id$ vs. $Id:$ ? Does that make any difference?

          bsantarelli Do you think that make sense having this issue opened?

          Manuel Recena Soto added a comment - bsantarelli Do you think that make sense having this issue opened?

            Unassigned Unassigned
            bsantarelli bsantarelli
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: