Maven 2.x Release Plugin

release:branch hit remoteTagging problem

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 2.0-beta-9
  • Fix Version/s: 2.0
  • Component/s: branch
  • Labels:
    None
  • Number of attachments :
    0

Description

I ran:

mvn release:branch -DbranchName=rlp_7.1

and got ...

[INFO] Working directory: /Users/benson/x/rex2009-trunk/java
org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml' already exists

	at org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
	at org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
	at org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
	at org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
	at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
	at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
	at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml' already exists

Issue Links

Activity

Hide
Stephen Connolly added a comment -

Did you have a mixed revision working copy?

I have seen this type of issue just creating tags using svn directly.

If you modify files locally, commit just those files and then do an svn cp without doing an svn update first, then you can end up with the above issue.

If this is a case of a mixed revision working copy, then there may not be an easy way to fix this, we could force an svn update, but that might be counter to what the user is trying to do, e.g. they may want to branch from their working copy... which has some files updated to HEAD while others have not been updated (because the update would break the code)

Show
Stephen Connolly added a comment - Did you have a mixed revision working copy? I have seen this type of issue just creating tags using svn directly. If you modify files locally, commit just those files and then do an svn cp without doing an svn update first, then you can end up with the above issue. If this is a case of a mixed revision working copy, then there may not be an easy way to fix this, we could force an svn update, but that might be counter to what the user is trying to do, e.g. they may want to branch from their working copy... which has some files updated to HEAD while others have not been updated (because the update would break the code)
Hide
Benson Margulies added a comment -

I don't think so. I started with a clean, up'ed, working copy, ran mvn, and got what I reported.

Show
Benson Margulies added a comment - I don't think so. I started with a clean, up'ed, working copy, ran mvn, and got what I reported.
Hide
werner mueller added a comment - - edited

a similar issue was solved in MRELEASE-427
since debian 5.0 stable runs with subversion 1.5 this may be around for a while.

edit: seems to have been fixed on trunk MRELEASE-461

Show
werner mueller added a comment - - edited a similar issue was solved in MRELEASE-427 since debian 5.0 stable runs with subversion 1.5 this may be around for a while. edit: seems to have been fixed on trunk MRELEASE-461
Hide
Benson Margulies added a comment -

It's already linked as a dup of a closed issue.

Show
Benson Margulies added a comment - It's already linked as a dup of a closed issue.

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: