Maven SCM
  1. Maven SCM
  2. SCM-406

scm tag does not work with Subversion 1.5.1

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.2
    • Component/s: maven-scm-provider-svn
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      scm:checkin does not work with Subversion 1.5.1

      On release:perform (which I assume calls scm:checkin) the following error occurs:

      svn: File '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml' already exists
      

      Using subversion 1.4.x is a good enough workaround.

        Issue Links

          Activity

          Hide
          James William Dumay added a comment -

          I'd like to also add that I've tested this on both Ubuntu linux and Mac OS X 10.5 using the CollabNet binaries.

          Show
          James William Dumay added a comment - I'd like to also add that I've tested this on both Ubuntu linux and Mac OS X 10.5 using the CollabNet binaries.
          Hide
          Olivier Lamy added a comment -

          Are you sure it's not a subversion tool issue ?

          Show
          Olivier Lamy added a comment - Are you sure it's not a subversion tool issue ?
          Hide
          James William Dumay added a comment -

          Not sure - it could be some variation of the --non-interactive issues that have been cropping up now and again. Ill setup a debugger and check it out again.

          Show
          James William Dumay added a comment - Not sure - it could be some variation of the --non-interactive issues that have been cropping up now and again. Ill setup a debugger and check it out again.
          Hide
          James William Dumay added a comment -

          I can confirm that this is a tooling problem in maven.

          The command executed is:

          svn --non-interactive copy --file /tmp/maven-scm-33408250.commit . https://svn.atlassian.com/svn/private/atlassian/release-testing/tags/maven-release-testing-2
          
          Show
          James William Dumay added a comment - I can confirm that this is a tooling problem in maven. The command executed is: svn --non-interactive copy --file /tmp/maven-scm-33408250.commit . https: //svn.atlassian.com/svn/ private /atlassian/release-testing/tags/maven-release-testing-2
          Hide
          James William Dumay added a comment -

          Changing the summary to show the correct name of operation.

          Show
          James William Dumay added a comment - Changing the summary to show the correct name of operation.
          Hide
          James William Dumay added a comment -
          Show
          James William Dumay added a comment - Problem has been discussed at length here: http://www.nabble.com/Release-fails-during-SVN-commit-td19084270.html
          Hide
          Vincent Siveton added a comment -

          I got this issue. Here are some workarounds from dkulp and olamy:

          # mvn release:prepare
          => fails
          # svn up -r head 
          # mvn release:prepare -Dresume
          

          using latest svn in your path and call svn cleanup (if you used TortoiseSVN, kill the TSVNCache too)

          Show
          Vincent Siveton added a comment - I got this issue. Here are some workarounds from dkulp and olamy: # mvn release:prepare => fails # svn up -r head # mvn release:prepare -Dresume using latest svn in your path and call svn cleanup (if you used TortoiseSVN, kill the TSVNCache too)
          Hide
          Grégory Joseph added a comment -

          Has anyone had a chance to test with a 1.5.2 client ? (source released Aug 30th, no binary for osx yet, afaik)

          Show
          Grégory Joseph added a comment - Has anyone had a chance to test with a 1.5.2 client ? (source released Aug 30th, no binary for osx yet, afaik)
          Hide
          Grégory Joseph added a comment - - edited

          Good news, I guess: using the macports.org port of the subversion client 1.5.2, this now seems to work.
          edit: i spoke too fast: it seems to work for single module projects (which was maybe the case with 1.5.1 too) but not with multi-module projects.

          Show
          Grégory Joseph added a comment - - edited Good news, I guess: using the macports.org port of the subversion client 1.5.2, this now seems to work. edit: i spoke too fast: it seems to work for single module projects (which was maybe the case with 1.5.1 too) but not with multi-module projects.
          Hide
          James William Dumay added a comment -

          I can still confirm this issue with the SVN 1.5.2 release.

          Show
          James William Dumay added a comment - I can still confirm this issue with the SVN 1.5.2 release.
          Hide
          Michael Johns added a comment -

          I have a little color I can add to this discussion. We too use Maven, but I'm 99% sure this has nothing to do with it. Here's what I've done:

          1. Ran a release in Maven; failed with the error everyone else is seeing (svn: File '...' already exists) 2. In a command prompt on our build box, changed to the project's working directory that was created by the Maven build. From there, ran a "svn --non-interactive copy -m <message> . <test destination>" manually (same command that Maven runs, save for an explicit message rather than --file). Got the same error.
          2. Queried the working copy to see if any files were changed. No files were changed, but about 10 new files were present (relics from the aborted build).
          3. Deleted the new files and ran the command again. Failed again with same error.
          4. Ran an update on my working copy. No changes happened (no new files, deleted files, or changed files), but something happened because...
          5. Ran the command again, and it worked.

          Some things to note:

          • We have a multi-module project.
          • We're on Windows Server 2003.
          • I installed SVN using various methods (msi, unzip), and they all fail. We have 1.5.2 with the Apache 2.0 bindings.
          • This problem doesn't happen with SVN 1.5.0, but it does happen with 1.5.1.

          To me, this most definitely appears to be a SVN bug. I've also posted this to the subversion users mailing list since it's really more relevant to them. But I figured I'd cross-post it here to help exonerate Maven as the culprit.

          Show
          Michael Johns added a comment - I have a little color I can add to this discussion. We too use Maven, but I'm 99% sure this has nothing to do with it. Here's what I've done: Ran a release in Maven; failed with the error everyone else is seeing (svn: File '...' already exists) 2. In a command prompt on our build box, changed to the project's working directory that was created by the Maven build. From there, ran a "svn --non-interactive copy -m <message> . <test destination>" manually (same command that Maven runs, save for an explicit message rather than --file). Got the same error. Queried the working copy to see if any files were changed. No files were changed, but about 10 new files were present (relics from the aborted build). Deleted the new files and ran the command again. Failed again with same error. Ran an update on my working copy. No changes happened (no new files, deleted files, or changed files), but something happened because... Ran the command again, and it worked. Some things to note: We have a multi-module project. We're on Windows Server 2003. I installed SVN using various methods (msi, unzip), and they all fail. We have 1.5.2 with the Apache 2.0 bindings. This problem doesn't happen with SVN 1.5.0, but it does happen with 1.5.1. To me, this most definitely appears to be a SVN bug. I've also posted this to the subversion users mailing list since it's really more relevant to them. But I figured I'd cross-post it here to help exonerate Maven as the culprit.
          Hide
          Alison Winters added a comment -

          This does appear to be an SVN "bug" in the sense that it doesn't let you tag from a non-head revision, even if all the files in and below the current directory are in fact at the latest revision for that directory on the repository. I think perhaps Maven should hide this by explicitly running an svn up prior to the svn copy - it makes sense anyways because presumably you do always want to release from the head version of what's in the repository.

          Show
          Alison Winters added a comment - This does appear to be an SVN "bug" in the sense that it doesn't let you tag from a non-head revision, even if all the files in and below the current directory are in fact at the latest revision for that directory on the repository. I think perhaps Maven should hide this by explicitly running an svn up prior to the svn copy - it makes sense anyways because presumably you do always want to release from the head version of what's in the repository.
          Hide
          Yann Albou added a comment -

          This issue still happens with SVN 1.5.3
          I don't know if it is an issue on SVN or on Maven side, but the issue can be resolved if we tag from repository instead of tagging from the local version.
          There is an open issue on this subject: SCM-262

          Show
          Yann Albou added a comment - This issue still happens with SVN 1.5.3 I don't know if it is an issue on SVN or on Maven side, but the issue can be resolved if we tag from repository instead of tagging from the local version. There is an open issue on this subject: SCM-262
          Hide
          Kyle Lebel added a comment -

          Hey guys, I downloaded the source code for the multiple dependencies (maven-release-plugin, maven-release-manager, maven-scm-providers-svn).

          If the maven-release-plugin you have is configured to use the latest, it will use 1.1 version of the maven-scm-providers. Simply changing the following line 162 in SvnTagCommand resolves this issue:

          cl.createArgument().setValue( "." );
          to
          cl.createArgument().setValue( repository.getUrl() );

          So not sure if someone would want to make an official revision for this. For now I will deploy this to our local maven repository.

          Show
          Kyle Lebel added a comment - Hey guys, I downloaded the source code for the multiple dependencies (maven-release-plugin, maven-release-manager, maven-scm-providers-svn). If the maven-release-plugin you have is configured to use the latest, it will use 1.1 version of the maven-scm-providers. Simply changing the following line 162 in SvnTagCommand resolves this issue: cl.createArgument().setValue( "." ); to cl.createArgument().setValue( repository.getUrl() ); So not sure if someone would want to make an official revision for this. For now I will deploy this to our local maven repository.
          Hide
          Kyle Lebel added a comment -

          Actually just after posting my comment I noticed this was already fixed in 1.1.1 - I guess the next step then to make this official is updating maven-release-plugin / manager? Anyone know the plans for this?

          Show
          Kyle Lebel added a comment - Actually just after posting my comment I noticed this was already fixed in 1.1.1 - I guess the next step then to make this official is updating maven-release-plugin / manager? Anyone know the plans for this?
          Hide
          Matthias Weßendorf added a comment -

          even wores, if your trunk is not named trunk... (b/c it is sometimes that case to have two trunks (to work on different "JSR specs")) but "trunk12_x"

          Anyway, so I run the plugin like :
          mvn release:prepare -DprepareRelease=true -Dresume -Dtag=http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.10

          now... I get this:
          [ERROR] BUILD FAILURE
          [INFO] ------------------------------------------------------------------------
          [INFO] Unable to tag SCM
          Provider message:
          The svn tag command failed.
          Command output:
          svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/asf/!svn/act/32a097b1-8097-af46-a3c1-55150b6042bd'

          [INFO] ------------------------------------------------------------------------

          Show
          Matthias Weßendorf added a comment - even wores, if your trunk is not named trunk... (b/c it is sometimes that case to have two trunks (to work on different "JSR specs")) but "trunk12_x" Anyway, so I run the plugin like : mvn release:prepare -DprepareRelease=true -Dresume -Dtag= http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.10 now... I get this: [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/asf/!svn/act/32a097b1-8097-af46-a3c1-55150b6042bd' [INFO] ------------------------------------------------------------------------
          Hide
          Matthias Weßendorf added a comment -

          for the problem above I had to do this:
          http://svn.apache.org/viewvc?view=rev&revision=713040

          now a "mvn release:prepare -DprepareRelease=true -Dresume" does the trick:

          However, still some clean ups, to be consistent:
          http://svn.apache.org/viewvc?view=rev&revision=713043
          http://svn.apache.org/viewvc?view=rev&revision=713044

          Show
          Matthias Weßendorf added a comment - for the problem above I had to do this: http://svn.apache.org/viewvc?view=rev&revision=713040 now a "mvn release:prepare -DprepareRelease=true -Dresume" does the trick: However, still some clean ups, to be consistent: http://svn.apache.org/viewvc?view=rev&revision=713043 http://svn.apache.org/viewvc?view=rev&revision=713044
          Hide
          Kalle Korhonen added a comment -

          Upgrading to svn 1.5.4 fixes the issue

          Show
          Kalle Korhonen added a comment - Upgrading to svn 1.5.4 fixes the issue
          Hide
          George Gastaldi added a comment -

          Kalle, I upgraded to 1.5.4 and the problem was not solved.

          Show
          George Gastaldi added a comment - Kalle, I upgraded to 1.5.4 and the problem was not solved.
          Hide
          Kalle Korhonen added a comment -

          Try together with release plugin 2.0-beta-8 - though I'm now seeing some oddities, need to verify it's not a user error when I release our project the next time (in a week)

          Show
          Kalle Korhonen added a comment - Try together with release plugin 2.0-beta-8 - though I'm now seeing some oddities, need to verify it's not a user error when I release our project the next time (in a week)
          Hide
          Tomislav Stojcevich added a comment -

          svn 1.5.4 with release plugin 2.0-beta-8, the problem still exists

          Show
          Tomislav Stojcevich added a comment - svn 1.5.4 with release plugin 2.0-beta-8, the problem still exists
          Hide
          Kuno Baeriswyl added a comment -

          I'd like to confirm that the problem still exists with svn 1.5.4 and release plugin 2.0-beta-8 (on Windows). Does anybody know if there is an offical bugreport from the subversion team I could track?

          Show
          Kuno Baeriswyl added a comment - I'd like to confirm that the problem still exists with svn 1.5.4 and release plugin 2.0-beta-8 (on Windows). Does anybody know if there is an offical bugreport from the subversion team I could track?
          Hide
          Kalle Korhonen added a comment -

          Agree, still a problem in svn 1.5.4, sorry for the noise. Only one of our project succeeded a release without issues because of a funny side effect of using the buildnumber plugin - it does svn update as part of the build (if configured so); which as other have pointed out, you can do manually as well to continue release:prepare after it fails the first time.

          Show
          Kalle Korhonen added a comment - Agree, still a problem in svn 1.5.4, sorry for the noise. Only one of our project succeeded a release without issues because of a funny side effect of using the buildnumber plugin - it does svn update as part of the build (if configured so); which as other have pointed out, you can do manually as well to continue release:prepare after it fails the first time.
          Hide
          Torsten Juergeleit added a comment - - edited

          Creating a copy (tag) on a working directory after performing a commit with SVN 1.5.1-1.5.4 seems to be an SVN issue
          (please refer to Error when creating tags from working copy).

          How about implementing the code change (using "cl.createArgument().setValue( repository.getUrl() );" instead of "cl.createArgument().setValue( "." ); ") suggested here by Kyle Lebel or in SCM-262?

          Show
          Torsten Juergeleit added a comment - - edited Creating a copy (tag) on a working directory after performing a commit with SVN 1.5.1-1.5.4 seems to be an SVN issue (please refer to Error when creating tags from working copy ). How about implementing the code change (using "cl.createArgument().setValue( repository.getUrl() );" instead of "cl.createArgument().setValue( "." ); ") suggested here by Kyle Lebel or in SCM-262 ?
          Hide
          Torsten Juergeleit added a comment -

          This would fix SCM-262

          Show
          Torsten Juergeleit added a comment - This would fix SCM-262
          Hide
          George Gastaldi added a comment -

          Torsten,

          If applied that patch, you could not solve the worst scenario: others may commit on trunk, so the tag created could not really be the one that you checked out and ran tests/packaged locally.

          What do you guys think about it ?

          Show
          George Gastaldi added a comment - Torsten, If applied that patch, you could not solve the worst scenario: others may commit on trunk, so the tag created could not really be the one that you checked out and ran tests/packaged locally. What do you guys think about it ?
          Hide
          Torsten Juergeleit added a comment -

          George,

          you're right. Hard-coding the update to trunk like the patch in SCM-262 doesn't fly.

          So how about the workaround suggested by Alison Winters to do "svn update" prior to the "svn copy" in ScmTagPhase?
          Maybe something like

          Index: src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java
          ===================================================================
          --- src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java	(revision 720901)
          +++ src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java	(working copy)
          @@ -61,8 +61,6 @@
           
                   validateConfiguration( releaseDescriptor );
           
          -        logInfo( relResult, "Tagging release with the label " + releaseDescriptor.getScmReleaseLabel() + "..." );
          -
                   ScmRepository repository;
                   ScmProvider provider;
                   try
          @@ -80,12 +78,35 @@
                       throw new ReleaseExecutionException( "Unable to configure SCM repository: " + e.getMessage(), e );
                   }
           
          +    	// TODO: want includes/excludes?
          +        ScmFileSet fileSet = new ScmFileSet( new File( releaseDescriptor.getWorkingDirectory() ) );
          +        
          +        // Due to a Subversion bug http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=686753
          +        // regarding the tag command (svn copy) we need to update the working directory first! 
          +        if ("svn".equals(provider.getScmType()))
          +        {
          +	        UpdateScmResult result;
          +	        try
          +	        {
          +            	logInfo( relResult, "Due to a Subversion bug we have to update the working directory before tagging ..." );
          +            	result = provider.update( repository, fileSet );
          +	        }
          +	        catch ( ScmException e )
          +	        {
          +	            throw new ReleaseExecutionException( "An error is occurred while updating working directory: " + e.getMessage(), e );
          +	        }
          +	
          +	        if ( !result.isSuccess() )
          +	        {
          +	            throw new ReleaseScmCommandException( "Unable to update working directory", result );
          +	        }
          +        }
          +        
                   TagScmResult result;
                   try
                   {
          -            // TODO: want includes/excludes?
          -            ScmFileSet fileSet = new ScmFileSet( new File( releaseDescriptor.getWorkingDirectory() ) );
                       String tagName = releaseDescriptor.getScmReleaseLabel();
          +            logInfo( relResult, "Tagging release with the label " + tagName + "..." );
                       result = provider.tag( repository, fileSet, tagName,
                                              releaseDescriptor.getScmCommentPrefix() + " copy for tag " + tagName );
                   }
          
          Show
          Torsten Juergeleit added a comment - George, you're right. Hard-coding the update to trunk like the patch in SCM-262 doesn't fly. So how about the workaround suggested by Alison Winters to do "svn update" prior to the "svn copy" in ScmTagPhase? Maybe something like Index: src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java =================================================================== --- src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java (revision 720901) +++ src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java (working copy) @@ -61,8 +61,6 @@ validateConfiguration( releaseDescriptor ); - logInfo( relResult, "Tagging release with the label " + releaseDescriptor.getScmReleaseLabel() + "..." ); - ScmRepository repository; ScmProvider provider; try @@ -80,12 +78,35 @@ throw new ReleaseExecutionException( "Unable to configure SCM repository: " + e.getMessage(), e ); } + // TODO: want includes/excludes? + ScmFileSet fileSet = new ScmFileSet( new File( releaseDescriptor.getWorkingDirectory() ) ); + + // Due to a Subversion bug http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=686753 + // regarding the tag command (svn copy) we need to update the working directory first! + if ( "svn" .equals(provider.getScmType())) + { + UpdateScmResult result; + try + { + logInfo( relResult, "Due to a Subversion bug we have to update the working directory before tagging ..." ); + result = provider.update( repository, fileSet ); + } + catch ( ScmException e ) + { + throw new ReleaseExecutionException( "An error is occurred while updating working directory: " + e.getMessage(), e ); + } + + if ( !result.isSuccess() ) + { + throw new ReleaseScmCommandException( "Unable to update working directory" , result ); + } + } + TagScmResult result; try { - // TODO: want includes/excludes? - ScmFileSet fileSet = new ScmFileSet( new File( releaseDescriptor.getWorkingDirectory() ) ); String tagName = releaseDescriptor.getScmReleaseLabel(); + logInfo( relResult, "Tagging release with the label " + tagName + "..." ); result = provider.tag( repository, fileSet, tagName, releaseDescriptor.getScmCommentPrefix() + " copy for tag " + tagName ); }
          Hide
          Kyle Lebel added a comment -

          This is true. My suggestion is flawed in a scenario where many developers risk committing to the trunk while building tags. In our situation, there are often many projects on the go with a manageable amount of developers (2-5) working on them. While building tags, we communicate to them to not commit to the trunk until the release is completed.

          But obviously this does not cover all scenarios.

          Show
          Kyle Lebel added a comment - This is true. My suggestion is flawed in a scenario where many developers risk committing to the trunk while building tags. In our situation, there are often many projects on the go with a manageable amount of developers (2-5) working on them. While building tags, we communicate to them to not commit to the trunk until the release is completed. But obviously this does not cover all scenarios.
          Hide
          George Gastaldi added a comment -

          And how about using SVNKit (http://www.svnkit.com) as the SVN provider ?
          Or another java implementation of SVN Client ? Is that possible ?

          Show
          George Gastaldi added a comment - And how about using SVNKit ( http://www.svnkit.com ) as the SVN provider ? Or another java implementation of SVN Client ? Is that possible ?
          Hide
          Thomas Dreyer added a comment -

          Using subversion 1.5.0 is also a good workaround for the moment.

          As Peter writes in his blog: http://osi.fotap.org/2008/07/30/svn-151-breaks-maven-release-plugin/
          CollabNet Subversion 1.5.0 download: http://downloads-guests.open.collab.net/servlets/ProjectDocumentList?folderID=6

          Show
          Thomas Dreyer added a comment - Using subversion 1.5.0 is also a good workaround for the moment. As Peter writes in his blog: http://osi.fotap.org/2008/07/30/svn-151-breaks-maven-release-plugin/ CollabNet Subversion 1.5.0 download: http://downloads-guests.open.collab.net/servlets/ProjectDocumentList?folderID=6
          Hide
          Alison Winters added a comment -

          I think Torsten is on the right track here. If you svn update the directory before tagging it will work by using the current directory ("."). To protect against the scenario where someone else might have updated trunk in between i think we could look at the following fix (sorry for pseudo code, i'm not familiar enough with the Maven internals to provide a real patch).

          boolean forceUpdate = getForceUpdateArgument();
          int revision = getHeadRevision();
          if (!forceUpdate && hasChanges(revision)) {
            println("Head revision has the following changes, do you wish to update?");
            printChanges(revision);
            if (!yesNo()) {
              return;
            }
          }
          update(revision);
          doTag(".");
          

          There is still a tiny race condition where someone checks something into head in between when you get the latest revision number and when you hit "yes" in non-force-update mode, but if that fails then it's no worse than the situation right now. This will at least fix the case for most of us who have segmented trees where it is very unlikely we will be tagging something from a branch that anyone else is simultaneously editing.

          Show
          Alison Winters added a comment - I think Torsten is on the right track here. If you svn update the directory before tagging it will work by using the current directory ("."). To protect against the scenario where someone else might have updated trunk in between i think we could look at the following fix (sorry for pseudo code, i'm not familiar enough with the Maven internals to provide a real patch). boolean forceUpdate = getForceUpdateArgument(); int revision = getHeadRevision(); if (!forceUpdate && hasChanges(revision)) { println( "Head revision has the following changes, do you wish to update?" ); printChanges(revision); if (!yesNo()) { return ; } } update(revision); doTag( "." ); There is still a tiny race condition where someone checks something into head in between when you get the latest revision number and when you hit "yes" in non-force-update mode, but if that fails then it's no worse than the situation right now. This will at least fix the case for most of us who have segmented trees where it is very unlikely we will be tagging something from a branch that anyone else is simultaneously editing.
          Hide
          Alison Winters added a comment -

          Just to clarify possible ambiguity in my pseudocode:

          getForceUpdateArgument() - command line argument to Maven
          getHeadRevision() - svn info http://server/path/to/repository@HEAD
          printChanges()/hasChanges() - svn status -u . (filtered to changes < $revision)
          update() - svn update -r $revision .

          Show
          Alison Winters added a comment - Just to clarify possible ambiguity in my pseudocode: getForceUpdateArgument() - command line argument to Maven getHeadRevision() - svn info http://server/path/to/repository@HEAD printChanges()/hasChanges() - svn status -u . (filtered to changes < $revision) update() - svn update -r $revision .
          Hide
          Yann Albou added a comment -

          Why not using the SVN lock and then release lock when the tag is done ?

          By doing this we will prevent others to commit changes during the tag.

          Show
          Yann Albou added a comment - Why not using the SVN lock and then release lock when the tag is done ? By doing this we will prevent others to commit changes during the tag.
          Hide
          Kuno Baeriswyl added a comment -

          [Using subversion 1.5.0 is also a good workaround for the moment. ]

          Unfortunately, it isn't. Generally, this version is not recommended for productive use. And I've got other show stoppers using this version.

          Show
          Kuno Baeriswyl added a comment - [Using subversion 1.5.0 is also a good workaround for the moment. ] Unfortunately, it isn't. Generally, this version is not recommended for productive use. And I've got other show stoppers using this version.
          Hide
          Johannes Schneider added a comment -

          Please fix this! It has been reported a few months ago and is a real show stopper.
          Most of the people out there use Subversion - and nearly everyone has to release a piece of software somewhen...

          I really wait for some competition for Maven....

          Sorry for ranting - but sometimes it is necessary...

          Show
          Johannes Schneider added a comment - Please fix this! It has been reported a few months ago and is a real show stopper. Most of the people out there use Subversion - and nearly everyone has to release a piece of software somewhen... I really wait for some competition for Maven.... Sorry for ranting - but sometimes it is necessary...
          Hide
          Justin Edelson added a comment -

          Does anyone know if an issue has been filed with Subversion for this? Has it been acknowledged as a bug on their end?

          Show
          Justin Edelson added a comment - Does anyone know if an issue has been filed with Subversion for this? Has it been acknowledged as a bug on their end?
          Hide
          Al Robertson added a comment -

          Following up Johannes's rant... this IS a real problem for us too!
          Can I assume everyone else using Maven/Subversion has not upgraded to 1.5.x? Otherwise - not using the release plugin. I guess I thought it would be effecting more people than the 55 voters.
          We have a server running 1.4.x specifically for releasing at the moment. It also means we can't upgrade the subversion repos to 1.5 until this is fixed.
          I know the answer - fix it yourself. I just felt I needed to comment on this one because it's stopping us using svn 1.5.

          Show
          Al Robertson added a comment - Following up Johannes's rant... this IS a real problem for us too! Can I assume everyone else using Maven/Subversion has not upgraded to 1.5.x? Otherwise - not using the release plugin. I guess I thought it would be effecting more people than the 55 voters. We have a server running 1.4.x specifically for releasing at the moment. It also means we can't upgrade the subversion repos to 1.5 until this is fixed. I know the answer - fix it yourself. I just felt I needed to comment on this one because it's stopping us using svn 1.5.
          Hide
          George Gastaldi added a comment -

          Al,

          You may upgrade your server to svn 1.5, and use svn client 1.5.0 (download link in previous comments). This is what I am using now.

          Regards,

          George Gastaldi

          Show
          George Gastaldi added a comment - Al, You may upgrade your server to svn 1.5, and use svn client 1.5.0 (download link in previous comments). This is what I am using now. Regards, George Gastaldi
          Hide
          Kent Lam added a comment -

          I made a bat file to do the release, this is what i do in the script until this problem is fixed:

          echo Preparing the release...
          call mvn release:clean release:prepare -Darguments=-Pproduction
          if %ERRORLEVEL% NEQ 0 goto retry

          :retry
          echo !!! Failure could be due to SVN 1.5 problem of tagging http://jira.codehaus.org/browse/SCM-406, Going to update, then retry mvn release:prepare!!!
          svn up
          call mvn release:prepare -Darguments=-Pproduction
          if %ERRORLEVEL% NEQ 0 goto failed
          goto preparesuccess

          :preparesuccess
          echo *** Please confirm that the Prepare was successful!
          echo *** Ctrl-C if the Prepare was NOT successful.
          pause

          :failed
          cd
          echo !!! Failed to release! Please fix issues and rerun script.
          goto finished

          Show
          Kent Lam added a comment - I made a bat file to do the release, this is what i do in the script until this problem is fixed: echo Preparing the release... call mvn release:clean release:prepare -Darguments=-Pproduction if %ERRORLEVEL% NEQ 0 goto retry :retry echo !!! Failure could be due to SVN 1.5 problem of tagging http://jira.codehaus.org/browse/SCM-406 , Going to update, then retry mvn release:prepare!!! svn up call mvn release:prepare -Darguments=-Pproduction if %ERRORLEVEL% NEQ 0 goto failed goto preparesuccess :preparesuccess echo *** Please confirm that the Prepare was successful! echo *** Ctrl-C if the Prepare was NOT successful. pause :failed cd echo !!! Failed to release! Please fix issues and rerun script. goto finished
          Hide
          Clint Gilbert added a comment - - edited

          George,

          I've heard that there are some major problems with SVN 1.5.0 that are fixed with later releases, potentially making 1.5.0 a bad option. Can anyone elaborate on this?

          Show
          Clint Gilbert added a comment - - edited George, I've heard that there are some major problems with SVN 1.5.0 that are fixed with later releases, potentially making 1.5.0 a bad option. Can anyone elaborate on this?
          Hide
          Clint Gilbert added a comment -

          It makes sense to tag from the local copy, since that's the code that's just been compiled and tested. Someone could have checked in a breaking change to the trunk which you wouldn't want in the release, for instance.

          But how about this (I'm just brainstorming; I don't know enough about the SCM code to know how feasible this is)?

          • release:prepare runs, updating poms, removing -SNAPSHOT from versions, etc.
          • The release plugin checks in the updated poms. If there's an error (the working copy is out of date, say), notify the user to update and re-try release:prepare
          • The release plugin records the revision number of the commit
          • The release plugin tags (via a remote URL) the recorded trunk revision as the release
          • The release plugin updates the needed poms to new snapshot versions and checks them in.

          I hope there's a fix for this soon; we're fine with SVN 1.4.x for now, but it would be much more convenient to be able to upgrade.

          Show
          Clint Gilbert added a comment - It makes sense to tag from the local copy, since that's the code that's just been compiled and tested. Someone could have checked in a breaking change to the trunk which you wouldn't want in the release, for instance. But how about this (I'm just brainstorming; I don't know enough about the SCM code to know how feasible this is)? release:prepare runs, updating poms, removing -SNAPSHOT from versions, etc. The release plugin checks in the updated poms. If there's an error (the working copy is out of date, say), notify the user to update and re-try release:prepare The release plugin records the revision number of the commit The release plugin tags (via a remote URL) the recorded trunk revision as the release The release plugin updates the needed poms to new snapshot versions and checks them in. I hope there's a fix for this soon; we're fine with SVN 1.4.x for now, but it would be much more convenient to be able to upgrade.
          Hide
          Kuno Baeriswyl added a comment -

          I've contacted the subversion developer list. Nobody of the subversion team seams to be aware of this problem...as a consequence, the issue won't get fixed...

          Can anybody reproduce the problem with subversion? Or does anybody know exactly what does not work with subversion?

          If so, please report it the topic in the developer list : http://www.nabble.com/Maven-scm-tag-does-not-work-with-Subversion-1.5.x-td20930592.html

          THanks a lot. I hope we can fixed it this way.

          Kuno

          Show
          Kuno Baeriswyl added a comment - I've contacted the subversion developer list. Nobody of the subversion team seams to be aware of this problem...as a consequence, the issue won't get fixed... Can anybody reproduce the problem with subversion? Or does anybody know exactly what does not work with subversion? If so, please report it the topic in the developer list : http://www.nabble.com/Maven-scm-tag-does-not-work-with-Subversion-1.5.x-td20930592.html THanks a lot. I hope we can fixed it this way. Kuno
          Hide
          Brent Plump added a comment -

          The core subversion issue is tracked here: http://subversion.tigris.org/issues/show_bug.cgi?id=3119 Daniel Shahaf's comment (posted on December 31) links to a good summary of the issue.

          Unless the release/scm plugins implement a workaround, we'll need to wait for this issue to be fixed by the svn team.

          In the meantime, I am using svn 1.5.0 for release actions and the current version for the rest of my work.

          Show
          Brent Plump added a comment - The core subversion issue is tracked here: http://subversion.tigris.org/issues/show_bug.cgi?id=3119 Daniel Shahaf's comment (posted on December 31) links to a good summary of the issue. Unless the release/scm plugins implement a workaround, we'll need to wait for this issue to be fixed by the svn team. In the meantime, I am using svn 1.5.0 for release actions and the current version for the rest of my work.
          Hide
          Dan Tran added a comment -

          From last view comments, the fix will be at SVN side. The bug will be moved out of 1.1.1 release and probably will not get fixed since we do have work around

          Show
          Dan Tran added a comment - From last view comments, the fix will be at SVN side. The bug will be moved out of 1.1.1 release and probably will not get fixed since we do have work around
          Hide
          Martin Nilsson added a comment -

          I have experienced the same problem, but after changing the protocol from http to svn (i.e. using svnserve instead of apache) I managed to release without the error.

          I'm using svn 1.5.5

          Show
          Martin Nilsson added a comment - I have experienced the same problem, but after changing the protocol from http to svn (i.e. using svnserve instead of apache) I managed to release without the error. I'm using svn 1.5.5
          Hide
          Justin Edelson added a comment -

          Has anyone tested this against Subversion 1.6 RC2?

          Show
          Justin Edelson added a comment - Has anyone tested this against Subversion 1.6 RC2?
          Hide
          Johan van Ee added a comment -

          Is there any news when this bug will be fixed in subversion?

          Show
          Johan van Ee added a comment - Is there any news when this bug will be fixed in subversion?
          Hide
          Stephen Connolly added a comment -

          There are some reports I saw a month back on the subversion mailing list that this is an issue with the neon transport. If you use the serf transport the problem goes away.

          AFAIK the situation is as follows:

          svn:// always works
          svn+ssh:// always works
          http:// only works with serf (I have not confirmed this yet)
          https:// only works with serf (I have not confirmed this yet)

          Show
          Stephen Connolly added a comment - There are some reports I saw a month back on the subversion mailing list that this is an issue with the neon transport. If you use the serf transport the problem goes away. AFAIK the situation is as follows: svn:// always works svn+ssh:// always works http:// only works with serf (I have not confirmed this yet) https:// only works with serf (I have not confirmed this yet)
          Hide
          Olivier Lamy added a comment -

          see proposals added in SCM-262. This will need some changes in release plugin/manager too as the proposal won't be activated by default in order to preserve backward compatibility.
          I hope I will find some friends to test the "fix" (I prefer to call this a workaround to a svn issue !)

          Show
          Olivier Lamy added a comment - see proposals added in SCM-262 . This will need some changes in release plugin/manager too as the proposal won't be activated by default in order to preserve backward compatibility. I hope I will find some friends to test the "fix" (I prefer to call this a workaround to a svn issue !)
          Hide
          Olivier Lamy added a comment -

          So I close this issue because it's now possible to tag remotely with the svnexe provider.
          Concerning issue with the release plugin, have a look at MRELEASE-427.

          Show
          Olivier Lamy added a comment - So I close this issue because it's now possible to tag remotely with the svnexe provider. Concerning issue with the release plugin, have a look at MRELEASE-427 .
          Hide
          Stefan Sperling added a comment -

          The underlying problem in Subversion has been fixed in 1.6.5.
          See http://subversion.tigris.org/issues/show_bug.cgi?id=3119
          and the 1.6.5 entry in http://svn.collab.net/repos/svn/trunk/CHANGES

          Maybe the plugin should limit use of its workaround to affected versions only?

          Show
          Stefan Sperling added a comment - The underlying problem in Subversion has been fixed in 1.6.5. See http://subversion.tigris.org/issues/show_bug.cgi?id=3119 and the 1.6.5 entry in http://svn.collab.net/repos/svn/trunk/CHANGES Maybe the plugin should limit use of its workaround to affected versions only?

            People

            • Assignee:
              Olivier Lamy
              Reporter:
              James William Dumay
            • Votes:
              98 Vote for this issue
              Watchers:
              86 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: