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.

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

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.

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

Changing the summary to show the correct name of operation.

Problem has been discussed at length here:
http://www.nabble.com/Release-fails-during-SVN-commit-td19084270.html

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)

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

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.

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

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.

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.

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

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.

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?

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] ------------------------------------------------------------------------

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

Upgrading to svn 1.5.4 fixes the issue

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

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)

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

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?

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.

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?

This would fix SCM-262

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 ?

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 );
         }

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.

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

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

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.

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 .

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.

[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.

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...

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

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.

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

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

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?

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.

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

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.

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

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

Has anyone tested this against Subversion 1.6 RC2?

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

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)

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 !)

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.

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?