[
http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177092#action_177092
]
Mark Struberg commented on SCM-444:
-----------------------------------
Hi Nigel!
I've discussed this in length with Brian and Jason a few weeks ago.
Imho we cannot spare the git-push, because the mvn release:perform will also
deploy the artifacts to a public repo!
What happens if the local tag will never get pushed?
I'm not saying that the wish for a local release is not valid, but this would
require a mandatory change of the way the release process works. So this is not
a simple maven-scm change but mainly one in the release-manager. (There is btw
also a wish from Brian to do a 'local checkout' into target/checkout instead of
freshly cloning the upstream repo, we should at least keep this in mind.)
How could it work:
$> mvn release:prepare
will do a local tag and does all the build, test, etc
$> mvn release:localperform
will get the local tag, 'export' this tag to target/checkout and does a build
test etc on a 'clean' location. This step will _not_ deploy the generated
artifacts!
$> mvn release:publish
will push the tag to the upstream repo and maybe deploy the previously
generated artifacts to the public repo.
I personally would like to mandatorily have a clone from the upstream repo and
then do a clean local build first instead of the direct deploy.
This sounds paranoid at the first glimpse, but from the point of safety it's
more mature.
Btw, the 2 branches in your example cannot be handled even in SVN. You only can
do this by manually tagging. But since git and hg always taggs the _whole_ repo
(there is no way to tag single directories!), it's not applicable to most
distributed SCMs anyway.
LieGrue,
strub
> Git provider does 'git push' during 'mvn release:prepare' which causes
> unwanted problems
> ----------------------------------------------------------------------------------------
>
> Key: SCM-444
> URL: http://jira.codehaus.org/browse/SCM-444
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
> Affects Versions: 1.1
> Reporter: Petter Måhlén
> Assignee: Olivier Lamy
> Priority: Minor
> Fix For: 1.3
>
>
> When doing 'mvn release:prepare' with a Git provider, a 'git push' command is
> executed. This is not ideal because the push command can fail or push things
> from the local repository that are not needed/wanted in the remote
> repository. Some examples are:
> 1. The local repository has two branches: master (tracking origin/master) and
> dummy (tracking origin/dummy). The release is being made on the master
> branch, and the dummy and origin/dummy branches have diverged. Running
> 'release:prepare' causes a 'git push', which will succeed for the master
> branch (assuming that the release preparation has been made correctly) and
> fail for the dummy branch (the two branches have diverged and need to be
> merged or rebased). The release preparation aborts and the directory is left
> in a somewhat inconsistent state where manual cleaning up is needed (removing
> pom.xml.next files, changing versions to <new>-SNAPSHOT, etc.)
> 2. The local repository has two branches: master (tracking origin/master) and
> localtest (not in the origin repository). The localtest branch shouldn't be
> published because it is just used for some temporary testing and doesn't even
> work. It will be pushed during 'release:prepare'.
> Suggested behaviour: use 'git push origin <currentbranch>:<currentbranch>',
> or even better, query for which remote repository to push to (found in
> .git/config) and which branch to push from and to. For me, it would be great
> to have a 'confirm push' before doing it so as to keep things clean, but
> maybe that is quite complex.
--
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
