[
http://jira.codehaus.org/browse/SCM-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated SCM-553:
-----------------------------
Fix Version/s: 1.5
Assignee: Olivier Lamy
> release:prepare not working with synergy scm-provider
> ------------------------------------------------------
>
> Key: SCM-553
> URL: http://jira.codehaus.org/browse/SCM-553
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-synergy
> Affects Versions: 1.3
> Environment: found and fixed on
> windows xp, service pack 3
> Synergy 6.5 build 4096
> java 1.6.0_18
> maven 3.0-alpha6
> Reporter: Jan Malcomess
> Assignee: Olivier Lamy
> Fix For: 1.5
>
> Attachments: maven-scm-provider-synergy.patch
>
>
> All the scm commands, as implemented in the synergy scm-provider, assume a
> default (synergy-)task or try to set one. However, all commands also stop the
> synergy session after they finish. This is no problem, when each command is
> run by itself.
> But, stopping the session also causes Synergy (at least our version 6.5 build
> 4096) to de-select the default task. This causes mvn release:prepare to fail,
> as the checked out and modified poms cannot be checked in because no default
> task (which is required by the check in command, as it is currently
> implemented) is set.
> Also, when tagging a version (which is done in Synergy by creating a
> baseline) the so-called prep-project is not updated, which means that the
> changed poms are not included in the baseline.
> I have attached a patch which fixes these issues for me and keeps the old
> behaviour largely unchanged so that people, who only use the provider to
> issue atomic scm-commands should encounter no changes EXCEPT one:
> Now, when a tag is to be created, the provider will always try to update
> (reconfigure) the project as specified by the scm-url (in the pom, usually
> the prep-project). This means, that all changes since the last update will
> automatically be included in the tagged version. Most of the time this is
> what you want, but it may be an issue if you end up including untested code.
> The easiest "workaround" is to declare a general code-freeze when tagging a
> version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
