[jira] Issue Comment Edited: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems

["Johannes Schneider (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207646#action_207646 ] 

Johannes Schneider edited comment on SCM-444 at 1/20/10 12:29 PM:
------------------------------------------------------------------

Mark: You are right. In an ideal world we would have transactions everywhere. Like in SQL. Then I'd prefer a separate step that uploads the artifacts to the repository and tags the "central" VCS repository within one transaction. And of course that step should support rollback...
(Maybe this might be a thing that should be implemented for Maven 4? I really love that idea...).

But at the moment Maven is far from that. 

And to be honest, I don't see your point in "we have to make sure that the tag gets pushed if the artifacts are going to be pushed to a public repo".
I understand that you try to keep the source and artifact repositories as consistent as possible. But the current situation is really not that good. 
When a release is done (with SVN) first the tag is created, then the sources are checked out and build. And finally deployed to the artifact repository.
A bigger project that has many modules may take several hours to build (especially site!). So you have inconsistent repositories at least for some time. Guaranteed! For every release.
So consistency is a good wish. But nothing more. And faking pseudo consistency through forced pushes is not the solution.

By the way: How does Maven handle commits/pushes to the source repository during release? I think that could/will brake the release, won't it?

The downside of the forced pushes is obvious: It is not possible to test Maven releases. So quite often Maven releases fail (at least in my projects, but maybe I am just unlucky). And every failed release pollutes the source repository. With Git it is possible to clean that up. With Subversion it is not...


My conclusion: We cannot ensure consistency between source and artifact repository. All we can do, is to fake some type of hopefully-will-be-consistent-in-a-few-minutes-again thing.
So just drop that idea until some *real* transaction support can be added. Until then, let the developer decide.
Just give us an option. I am not begging that you change *your* workflow. Just try to see the disadvantages of the current behaviour and give us an option to avoid them...



The additional release:stage seems to be a good idea. It helps to solve problematic release.
But it does not solve the issue of consistency. When release:perform just uploads the artifacts and tags the source repository, several problems might occur:
- One of them fails and we have a nice inconsistency (just think about permission issues or network problems)
- at least we have a short time where those repositories are not consistent


      was (Author: jschneider):
    Mark: You are right. In an ideal world we would have transactions everywhere. Like in SQL. Then I'd prefer a separate step that uploads the artifacts to the repository and tags the "central" VCS repository within one transaction. And of course that step should support rollback...
(Maybe this might be a thing that should be implemented for Maven 4? I really love that idea...).

But at the moment Maven is far from that. 

And to be honest, I don't see your point in "we have to make sure that the tag gets pushed if the artifacts are going to be pushed to a public repo".
I understand that you try to keep the source and artifact repositories as consistent as possible. But the current situation is really not that good. 
When a release is done (with SVN) first the tag is created, then the sources are checked out and build. And finally deployed to the artifact repository.
A bigger project that has many modules may take several hours to build (especially site!). So you have inconsistent repositories at least for some time. Guaranteed! For every release.
So consistency is a good wish. But nothing more. And faking pseudo consistency through forced pushes is not the solution.

By the way: How does Maven handle commits/pushes to the source repository during release? I think that could/will brake the release, won't it?

The downside of the forced pushes is obvious: It is not possible to test Maven releases. So quite often Maven releases fail (at least in my projects, but maybe I am just unlucky). And every failed release pollutes the source repository. With Git it is possible to clean that up. With Subversion it is not...


My conclusion: We cannot ensure consistency between source and artifact repository. All we can do, is to fake some type of hopefully-will-be-consistent-in-a-few-minutes-again thing.
So just drop that idea until some *real* transaction support can be added. Until then, let the developer decide.
Just give us an option. I am not begging that you change *your* workflow. Just try to see the disadvantages of the current behaviour and give us an option to avoid them...



  
> 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: Mark Struberg
>            Priority: Minor
>
> 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