scm:tag for subversion tagging from local version of code, not directly from repository

In my setup SVN repository is multiproject setup and tags/ directory can only be created in. It can't be modified.

I'm unable to use "svn release:prepare" due to it trying to do "svn copy . tag_url". I've made a patch that does "svn copy trunk_rul tag_url" and that makes it work fine. I think this is the right approach in general and is also more efficient from SVN perspective. Is there any chance this issue will be addressed in next release?

Index: src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/tag/SvnTagCommand.java
===================================================================
— src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/tag/SvnTagCommand.java (revision 586574)
+++ src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/tag/SvnTagCommand.java (working copy)
@@ -157,7 +157,8 @@

cl.createArgument().setValue( messageFile.getAbsolutePath() );

• cl.createArgument().setValue( "." );
  + String projectRoot = SvnTagBranchUtils.getProjectRoot(repository.getUrl());
  + cl.createArgument().setValue( projectRoot + "/trunk" );

// Note: this currently assumes you have the tag base checked out too
String tagUrl = SvnTagBranchUtils.resolveTagUrl( repository, new ScmTag
( tag ) );

This issue could resolve issue SCM-406

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 think about it ?

Yes, I agree with you.
But this worst scenario is not the most common.

Another way, would be to get a svn lock and then release lock when the tag is done.

Yann,

I may be wrong, but I know that there are some OS (Windows, for instance) that do not allow locking in SVN.
Also,locking the entire trunk would be overkill in a big team (take any apache project and you will see that).

George,
It seems to work on Windows.
Yes I agree with you it is overkill. but either we resolve the worst scenario with this overkill solution or we use a lighter solution that doesn't cover all situations....
Personnally, I prefer the simple solution where we tag from the repository.

Wouldn't it be possible to take the revision number at start of the release and give that to svn checkout and svn copy? Noone can change a revision so you will be save.

The svn command that fails is :

svn copy --file /tmp/maven-scm-297444897.commit . http://XXX/svn/project/tags/foo-1.0.0

Simply adding the explicit revision to copy from solves the problem

svn copy --file /tmp/maven-scm-297444897.commit -r 599 . http://XXX/svn/project/tags/foo-1.0.0

So is there an easy way for the SvnTagCommand to get the revision of the local copy?

Here is a patch that I made against version 1.0. It uses the svn info command on the working directory to get the current revision (presumably the revision that was built) and passes the revision to the svn cp command. This works with svn 1.5.4 (have not tested other versions, but dont see any reason it wouldnt).

Tagging from a fixed revision is only equivalent to tagging from a working copy if the working copy is at a consistent revision across all files, i.e. only if 'svn info -R | grep Revision' shows the same revision number for all files. Maven should enforce this at the same time as it checks for local modifications.

In fact, to be completely correct, maven would have to be even more paranoid during release:prepare

• Check that svn st -u shows neither local nor remote changes. The output will also contain the latest revision for the tree on the server, call it R1
• svn up -r $R1. This should not result in any changes
• Commit the POM update, call the revision this results in R2
• Check that no intervening changes were committed on the server: svn log -q -r $R1:$R2. This should only return the two revisions R1 and R2, but nothing in between
• Making a tag of R2 will now have the same content as the original working copy (+ POM change)

My proposal is to use :

svn copy --file /tmp/maven-scm-297444897.commit -r 599 http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0

BTW to preserve backward comp this won't be the default way, it will be activated though an option.
I propose to add a new method in ScmProvider :

    TagScmResult tag( ScmRepository repository, ScmFileSet fileSet, String tagName, TagParameters tagParameters)
        throws ScmException;

String message;
boolean remoteTagging = false;
String scmRevision;

In the new tag method :

// really pseudo code but maven style :-)
if (!remoteTagging) 
{
  use current tag command
}
if (remoteTagging && scmRevision != null) 
{
  // this can be usefull to tag a particular svn rev (ie releasing one build in ci tools)
  svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision} http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
if (remoteTagging && scmRevision == null) 
{
  get the current svn with SvnInfoCommandResult;
  svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision} http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}

If no comments/objections I will implements this as it
BTW :

• we will have to add some new mojo parameters in the maven-release-plugin to be able to use in the release plugin
• others scm implementations will use their current Tag command (if remote tag is configured a warning will say "this scm implementation doesn't support remote tagging"$

work started with [rev 754778http://svn.apache.org/viewvc?rev=754778&view=rev

After some tests with the release plugin this doesn't work as this (or so easily)
Story :

• before starting the release your current local rev is 2
• after committing the released pom the svn rev on the server is 3
• but your current local rev is always 2 !
• when we copy : svn cp -r 2 ... .. we copy a non released pom (always SNAPSHOT version) to the tag path.

We have to get the new svn rev after committing the released pom and use it for the tag/copy operation.

Olivier,

Yes, this is something that I could not figure out how to solve.
I guess this is the right way.

I close this issue as it's now possible to tag remotely with svn provider (using ScmTagParameters.remoteTagging)