Thanks for the replies Roland, it's much appreciated, Here's some excerpts from the logs:
Here is a log with dryRun=false where you can see the copy command for the tag using the project root instead of trunk. Also you can see that unlike the other parts of the execution where the script starts by going to the /project/workspace directory the tag script starts by changing to the /project directory, the only reason this doesn't fail outright is that it's doing a copy instead of something that acts on the current working directory. [INFO] Checking in modified POMs... [INFO] Executing: /bin/sh -c cd /u/wc/hudson_work/jobs/project/workspace && svn --username user --password '*****' --non-interactive commit --file /tmp/maven-scm-2019473207.commit --targets /tmp/maven-scm-8595138965749612920-targets [INFO] Working directory: /u/wc/hudson_work/jobs/project/workspace [INFO] Tagging release with the label project-1.5.0... [INFO] Executing: /bin/sh -c cd /u/wc/hudson_work/jobs/project && svn --username user --password '*****' --non-interactive copy --file /tmp/maven-scm-1342382552.commit --revision 238615 https://subversion.mycompany.com/java/project https://subversion.mycompany.com/java/project/tags/project-1.5.0 [INFO] Working directory: /u/wc/hudson_work/jobs/project [INFO] Transforming 'Project - Flex'... [INFO] Transforming 'Project - Java'... [INFO] Transforming 'Project Proxy'... [INFO] Transforming 'Project Proxy/API WAR'... [INFO] Updating project-proxy to 1.6.0-SNAPSHOT [INFO] Transforming 'Project Publisher'... [INFO] Transforming 'Project Publisher War'... [INFO] Updating project-publisher to 1.6.0-SNAPSHOT [INFO] Transforming 'Project Tool WAR'... [INFO] Transforming 'Project EAR'... [INFO] Updating project-proxy-war to 1.6.0-SNAPSHOT [INFO] Updating project-tool-war to 1.6.0-SNAPSHOT [INFO] Updating project-publisher-war to 1.6.0-SNAPSHOT [INFO] Transforming 'Project Master POM'... [INFO] Not removing release POMs [INFO] Checking in modified POMs... [INFO] Executing: /bin/sh -c cd /u/wc/hudson_work/jobs/project/workspace && svn --username user --password '*****' --non-interactive commit --file /tmp/maven-scm-192511325.commit --targets /tmp/maven-scm-7940317626122164433-targets [INFO] Working directory: /u/wc/hudson_work/jobs/project/workspace [INFO] Release preparation complete. Here's a log segment where I did a dry run showing that it fully intends on tagging the project root instead of the trunk.: [INFO] Full run would be tagging remotely scm:svn: https://subversion.mycompany.com/java/project with label: 'project-master-1.2.0' Here's a log where I set remoteTagging to false and you can see that it is now hanging up on the fact that it changed directory to /project instead of all the way to the working directory (like all the other scripts do). In this case I added an additional directory to the workspace called toQA just to demonstrate that it seems to be a level issue rather than a hard coded path: [INFO] Checking in modified POMs... [INFO] Executing: /bin/sh -c cd /u/wc/hudson_work/jobs/project/workspace/toQA && svn --username dynamo --password '*****' --non-interactive commit --file /tmp/maven-scm-283313407.commit --targets /tmp/maven-scm-1186996888170714263-targets [INFO] Working directory: /u/wc/hudson_work/jobs/project/workspace/toQA [INFO] Tagging release with the label project-master-1.2.0... [INFO] Executing: /bin/sh -c cd /u/wc/hudson_work/jobs/project/workspace && svn --username user --password '*****' --non-interactive copy --file /tmp/maven-scm-777821000.commit . https://subversion.mycompany.com/java/project/tags/project-master-1.2.0 [INFO] Working directory: /u/wc/hudson_work/jobs/project/workspace These examples are obviously from a hudson server, but I've run it locally and experienced the same thing. Thanks again to anyone who has read this, even if you can't help me ;) Brent Brent Smith BScCS Software Developer, theREDspace Halifax, Nova Scotia, Canada Phone: 902.444.3490x3869 brent.sm...@theredspace.com On Tue, Apr 19, 2011 at 2:52 PM, Asmann, Roland <roland.asm...@adesso.at>wrote: > That looks correct to me... > And thinking about it, tagBase can't be the reason for this, since the > tag is actually in the right place. > > I'm afraid I don't know what else it could be... Maybe you could run a > release with debug-output and read something out of that? If not, you > could post it so all of us can take a crack at it. > >
