maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Struberg (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
Date Tue, 19 May 2009 10:31:44 GMT

    [ 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

       

Mime
View raw message