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

          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: