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

Svn-tagging failed on newly created branch

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Jenkins Subversion Tagging Plugin, version 1.16 fails to tag on a newly created branch.

      Subversion tag checks out:

      Checking out https://subversion03/svn/uniregrepos/branches/rel_20130413/src at revision '2013-03-20T14:50:45.673 +0100'
      .
      ..
      ...
      At revision 1061

      Remote Module Location: https://subversion03/svn/uniregrepos/branches/rel_20130413/src@1060.
      Tag Base URL: https://subversion03/svn/uniregrepos/tags/D20130320_SVN001060_B0001_REL_20130413_PATCH.
      There was no old tag at https://subversion03/svn/uniregrepos/tags/D20130320_SVN001060_B0001_REL_20130413_PATCH.
      Subversion copy failed. svn: E160013: Path 'https://subversion03/svn/uniregrepos/branches/rel_20130413/src' does not exist in revision 1,060
      Build step 'Perform Subversion tagging on successful build' marked build as failure


      It fails because the SVN Global Number for the newly created branch starts at #1061. The 'subversion tag' plugin picks SVN Global Number #1060.

      When I tried to commit to the newly created branch, the SVN Global Number is incremented and the subversion tag plugin works.

        Attachments

          Activity

          Hide
          hydra Dan Dickey added a comment -

          This problem has been plaguing me for a few years now.
          I finally took some time this morning to figure out what the problem is.
          Basically, the problem is that the svn-tag plugin is using the "Last Changed Revision" as determined by the SCM Poll when it should be using the "Current Revision" for a given URL of a job.
          Here, we create branches from the trunk and those are what we build and release. The branch builds. This is maybe opposite of what most people do? It seems that if all commits/merges were made to the trunk and builds were made from that (and tags), then everything would probably work nicely.
          Our problem here is that a build job consists of several to many URL's from svn. When we create a new branch, we of course copy the trunk to it. The last changed version exists back on the trunk, not on the branch now. So.... when svn-tag tries to copy .../branch/...@<last-changed-revision#> this fails because it doesn't exist on the branch. If a change is commited to the branch, then the last change revision changes of course and then things would work for svn-tag. But... we have some URLs in our jobs that do not change for years at a time. So... using the last changed revision way back on the trunk is not what we want. I would like an option to svn-tag to choose to use the current revision for an repoURL. This is not available in the revision.txt file, so would most likely have to be retrieved from the working copy of what we have checked out.

          This problem has obviously existed for a long time and has been reported and interpreted in many ways.
          This jira item was about the newest issue I could find that directly relates to this so I'm adding this comment here.
          k2nakamura - how can I help fix this? I can certainly help test a fix for it.

          Show
          hydra Dan Dickey added a comment - This problem has been plaguing me for a few years now. I finally took some time this morning to figure out what the problem is. Basically, the problem is that the svn-tag plugin is using the "Last Changed Revision" as determined by the SCM Poll when it should be using the "Current Revision" for a given URL of a job. Here, we create branches from the trunk and those are what we build and release. The branch builds. This is maybe opposite of what most people do? It seems that if all commits/merges were made to the trunk and builds were made from that (and tags), then everything would probably work nicely. Our problem here is that a build job consists of several to many URL's from svn. When we create a new branch, we of course copy the trunk to it. The last changed version exists back on the trunk, not on the branch now. So.... when svn-tag tries to copy .../branch/...@<last-changed-revision#> this fails because it doesn't exist on the branch. If a change is commited to the branch, then the last change revision changes of course and then things would work for svn-tag. But... we have some URLs in our jobs that do not change for years at a time. So... using the last changed revision way back on the trunk is not what we want. I would like an option to svn-tag to choose to use the current revision for an repoURL. This is not available in the revision.txt file, so would most likely have to be retrieved from the working copy of what we have checked out. This problem has obviously existed for a long time and has been reported and interpreted in many ways. This jira item was about the newest issue I could find that directly relates to this so I'm adding this comment here. k2nakamura - how can I help fix this? I can certainly help test a fix for it.
          Hide
          vincent_kirsch Vincent Kirsch added a comment -

          Hi,

          I have the exact same issue as described above by Dan.

          In an nutshell if a Jenkins project requires sources from several URLs, and that there was no commit on a branch from where we check out, the svn tagging for that url fails:

          org.tmatesoft.svn.core.SVNException: svn: E160013: Path 'https://repobase/svn/path/to/branch/path/to/module' does not exist in revision 46,531

          Would it be please possible to have a look?

          Thanks
          Vincent

          Show
          vincent_kirsch Vincent Kirsch added a comment - Hi, I have the exact same issue as described above by Dan. In an nutshell if a Jenkins project requires sources from several URLs, and that there was no commit on a branch from where we check out, the svn tagging for that url fails: org.tmatesoft.svn.core.SVNException: svn: E160013: Path 'https://repobase/svn/path/to/branch/path/to/module' does not exist in revision 46,531 Would it be please possible to have a look? Thanks Vincent

            People

            • Assignee:
              k2nakamura k2nakamura
              Reporter:
              nfredrik Fredrik Svärd
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: