maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Scm, Surefire, Wagon migrate to git (please check) [was Plan for git migration]
Date Fri, 21 Sep 2012 12:01:38 GMT
On 21 September 2012 12:58, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

>
>
> On 21 September 2012 12:40, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
>> > Are we d'accord that we must _not_ do releases on master but always
>> create a temporary branch for each release (and then merge back to master
>> after the vote passed) ?
>>
>> Now it's getting interesting:
>>
>> git clone git://git.apache.org/maven-surefire.git
>> cd maven-surefire
>> gitk --all &
>>
>> git clone https://github.com/sonatype/plexus-utils.git
>> cd plexus-utils
>> gitk --all &
>>
>>
>> Hold the two gitk windows side by side;)
>>
>> Now the tags in surefire seem like the textbook way to do this,
>> whereas plexus-utils has ugly tags. But is there any way to have
>> release-plugin actually *make* tags like surefire has ? (these are
>> from the asf git clone, so they have been created by some dark
>> magics...)
>>
>
> I think this is a side-effect of the svn-git migration
>
> the plexus ones are where the tag is created on the master branch
>
> the surefire ones are where the tag is created from a separate branch
> (i.e. the tag)
>
> to have the history like this in git you would do something like
>
> here is the way

# update poms
$ git commit -m "[maven-release-plugin] prepare release surefire-2.12.2"
$ git checkout -b temp
$ git commit --allow-empty -m "[maven-release-plugin] copy tag for
surefire-2.12.2"
$ git tag surefire-2.12.2
$ git checkout master
# update poms
$ git commit -m "[maven-release-plugin] prepare for next development
iteration"


>
>>
>> Kristian
>>
>>
>>
>>
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> >> From: Kristian Rosenvold <kristian.rosenvold@gmail.com>
>> >> To: Maven Developers List <dev@maven.apache.org>
>> >> Cc:
>> >> Sent: Friday, September 21, 2012 10:33 AM
>> >> Subject: Re: Scm, Surefire, Wagon migrate to git (please check) [was
>> Plan for git migration]
>> >>
>> >> You don't really "crash" anything, but if the tag is rewritten you
>> >> have to delete the local tag to actually get the updated reference to
>> >> the tag.
>> >>
>> >> The authorative repo is correct, but there may be some clones out
>> >> there that are unaware of the failed release and the moved tag.
>> >>
>> >> I still think the benefit of moving the tag > just tagging locally
>> >> (and hence missing tags).
>> >>
>> >> Could we introduce something like subtagging ? If the official release
>> >> tag is "xyz_plugin_1.2.3", could we have the release plugin tag the
>> >> first version as "xyz_plugin_1.2.3_0" and just automatically advance
>> >> the tag for each re-release ? Then we *could* have some automated step
>> >> in the post-vote process burniung the final release number based on
>> >> highest available subtag (and delete the subtags) ?
>> >>
>> >> I suppose a similar post-vote tool could also just push the local
>> >> release tag to the repo, so I may be complicating things.....?
>> >>
>> >> Kristian
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2012/9/20 Mark Struberg <struberg@yahoo.de>:
>> >>>  Hi folks!
>> >>>
>> >>>  The problem is the rollback.
>> >>>  In DeltaSpike we do _not_ push now. deleting a tag on one repo is
>> not a
>> >> problem, but you would crash all downstream clones as re-trying a
>> release is
>> >> basically a history rewrite.
>> >>>
>> >>>  In DeltaSpike I do the release locally and push the tag + release
>> branch to
>> >> my github clone (or any other public repo you like).
>> >>>  After the VOTE passes I merge it to master and push it to the ASF
>> canonical
>> >> repo.
>> >>>
>> >>>  Not perfect neither, but worked far better than history rewrites at
>> least
>> >> ;)
>> >>>
>> >>>  LieGrue,
>> >>>  strub
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>  ----- Original Message -----
>> >>>>  From: Kristian Rosenvold <kristian.rosenvold@gmail.com>
>> >>>>  To: Maven Developers List <dev@maven.apache.org>
>> >>>>  Cc:
>> >>>>  Sent: Thursday, September 20, 2012 4:56 PM
>> >>>>  Subject: Re: Scm, Surefire, Wagon migrate to git (please check)
[was
>> >> Plan for git migration]
>> >>>>
>> >>>>  I just checked and there is no general blocking for deleting tags.
>> We
>> >>>>  should definitely push as part of release plugin. Tags ar cheap.
>> >>>>
>> >>>>  Kristian
>> >>>>
>> >>>>
>> >>>>  2012/9/20 Olivier Lamy <olamy@apache.org>:
>> >>>>>   2012/9/20 Mark Derricutt <mark@talios.com>:
>> >>>>>>   Olivier,
>> >>>>>>
>> >>>>>>   I'm not checked yet ( not thru lazyness, but thru
>> >> buzyness, and
>> >>>>  shooting this email just as I think of it ), in all my local
>> maven/git
>> >> projects
>> >>>>  I set in the maven-release-plugin configuration:
>> >>>>>>
>> >>>>>>   <pushChanges>false</pushChanges>
>> >>>>>>   <localCheckout>true</localCheckout>
>> >>>>>>
>> >>>>>>   to prevent any upstream/origin pushes during release (
there
>> >> may not BE
>> >>>>  an origin/remote yet ). There was some discussion either on here,
>> or in
>> >> JIRA (
>> >>>>  not sure off hand which ) about making these options the default
for
>> >> any of the
>> >>>>  supported distributed version control systems.
>> >>>>>>
>> >>>>>>   Does anyone know if this was done? Should these options
be
>> >> mandated as
>> >>>>  a standard practise for maven+git conversion?
>> >>>>>
>> >>>>>   No release yet.
>> >>>>>   But regarding <pushChanges>false</pushChanges>,
I
>> >> remember we
>> >>>>  used on
>> >>>>>   jenkins side and everybody missed the manual step (push the
tag)
>> >> when
>> >>>>>   released. So we moved to true.
>> >>>>>   BTW it's something to discuss.
>> >>>>>   Maybe pushing the tag once release vote passed ?
>> >>>>>   I remember some discussions on ASF infra for blocking of tag
>> >> deletion
>> >>>>>   (I don't know if this has been applied on the final infra)
>> >> because we
>> >>>>>   sometimes delete tags if the release vote fail.
>> >>>>>   I can test creating a fake tag and try delete it :-)
>> >>>>>
>> >>>>>>
>> >>>>>>   Mark
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>   On 20/09/2012, at 1:40 AM, Olivier Lamy
>> >> <olamy@apache.org> wrote:
>> >>>>>>
>> >>>>>>>   BTW I have started a page here:
>> >>>>>>>   http://maven.apache.org/developers/conventions/git.html
>> >>>>>>>
>> >>>>>>>   we could put some git tips and more conventions.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>   2012/9/18 Arnaud Héritier <aheritier@gmail.com>:
>> >>>>>>>>   My remarks about these repos :
>> >>>>>>>>   * trunk will have to be renamed master (I'm not
>> >> sure if
>> >>>>  we'll go further
>> >>>>>>>>   like using the git workflow with the develop branch
to
>> >> keep
>> >>>>  master as
>> >>>>>>>>   stable as possible - In any case I would recommand
to
>> >> follow a
>> >>>>  convention
>> >>>>>>>>   fix/XXXX, stable/A.B.C, feature/ZZZZ to organize
>> >> branches)
>> >>>>>>>>   * A strange thing I didn't have in my company
>> >> repositories
>> >>>>  I recently
>> >>>>>>>>   migrated is the commit/tag (copy for tag) for
each
>> >> release done
>> >>>>  by the
>> >>>>>>>>   release plugin. I don't know if it is a different
>> >> setting
>> >>>>  in the plugin or
>> >>>>>>>>   something cleaned by filters I applied in the
SVN
>> >> -> GIT
>> >>>>  migration we did
>> >>>>>>>>   * Some strange branches to cleanup ? ASF, APACHE
or by
>> >> user
>> >>>>  (trygvis,
>> >>>>>>>>   evenisse ...)
>> >>>>>>>>
>> >>>>>>>>   That's all what I see for now.
>> >>>>>>>>
>> >>>>>>>>   Cheers
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>   On Tue, Sep 18, 2012 at 8:29 PM, Arnaud Héritier
>> >>>>  <aheritier@gmail.com>wrote:
>> >>>>>>>>
>> >>>>>>>>>   I Will test them. Will they keep these ugly
URLs
>> >> git-wip-us
>> >>>>  in the
>> >>>>>>>>>   future ? I'm not a fanatic but I would prefer
>> >> to have
>> >>>>  something stable
>> >>>>>>>>>   to put in our POMs for releases. I know that
we
>> >> don't
>> >>>>  use often scm
>> >>>>>>>>>   infos after the release but it is sad if we
know
>> >> that
>> >>>>  they'll be
>> >>>>>>>>>   discontinued in a near future. No ?
>> >>>>>>>>>
>> >>>>>>>>>   Le 18 sept. 2012 à 19:23, Olivier Lamy
>> >>>>  <olamy@apache.org> a écrit :
>> >>>>>>>>>
>> >>>>>>>>>>   Repositories has been migrated to:
>> >>>>>>>>>>   *
>> >>>>  https://git-wip-us.apache.org/repos/asf/maven-surefire.git
>> >>>>>>>>>>   *
>> >>>>  https://git-wip-us.apache.org/repos/asf/maven-wagon.git
>> >>>>>>>>>>   *
>> >> https://git-wip-us.apache.org/repos/asf/maven-scm.git
>> >>>>>>>>>>   They are currently read only.
>> >>>>>>>>>>   Content looks good.
>> >>>>>>>>>>   If nobody complains, I will ask to move
to rw
>> >> mode
>> >>>>  tomorrow. (in 24H)
>> >>>>>>>>>>
>> >>>>>>>>>>   2012/9/18 Olivier Lamy
>> >> <olamy@apache.org>:
>> >>>>>>>>>>>   Hi
>> >>>>>>>>>>>   See
>> >>>>  https://issues.apache.org/jira/browse/INFRA-5266
>> >>>>>>>>>>>   Those tree svn paths will be readonly
now
>> >> for
>> >>>>  migration.
>> >>>>>>>>>>>
>> >>>>>>>>>>>   2012/9/12 Olivier Lamy
>> >> <olamy@apache.org>:
>> >>>>>>>>>>>>   Hi Folks,
>> >>>>>>>>>>>>   So the vote passed, now it's time
>> >> for
>> >>>>  volunteers to use their fingers
>> >>>>>>>>>   :-).
>> >>>>>>>>>>>>   I have started a page [1] for
ETA of
>> >> migration
>> >>>>  (note the Volunteer
>> >>>>>>>>>>>>   column :-) ) and for discussion
on
>> >> some stuff
>> >>>>  (plugins shared)
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>   Thanks
>> >>>>>>>>>>>>   --
>> >>>>>>>>>>>>   Olivier Lamy
>> >>>>>>>>>>>>   Talend: http://coders.talend.com
>> >>>>>>>>>>>>   http://twitter.com/olamy |
>> >>>>  http://linkedin.com/in/olamy
>> >>>>>>>>>>>>   [1]
>> >>>>  https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>   --
>> >>>>>>>>>>>   Olivier Lamy
>> >>>>>>>>>>>   Talend: http://coders.talend.com
>> >>>>>>>>>>>   http://twitter.com/olamy |
>> >>>>  http://linkedin.com/in/olamy
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>   --
>> >>>>>>>>>>   Olivier Lamy
>> >>>>>>>>>>   Talend: http://coders.talend.com
>> >>>>>>>>>>   http://twitter.com/olamy |
>> >> http://linkedin.com/in/olamy
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>
>>  ---------------------------------------------------------------------
>> >>>>>>>>>>   To unsubscribe, e-mail:
>> >>>>  dev-unsubscribe@maven.apache.org
>> >>>>>>>>>>   For additional commands, e-mail:
>> >>>>  dev-help@maven.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>   --
>> >>>>>>>>   -----
>> >>>>>>>>   Arnaud Héritier
>> >>>>>>>>   06-89-76-64-24
>> >>>>>>>>   http://aheritier.net
>> >>>>>>>>   Mail/GTalk: aheritier@gmail.com
>> >>>>>>>>   Twitter/Skype : aheritier
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>   --
>> >>>>>>>   Olivier Lamy
>> >>>>>>>   Talend: http://coders.talend.com
>> >>>>>>>   http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >>>>>>>
>> >>>>>>>
>> >>>>
>>  ---------------------------------------------------------------------
>> >>>>>>>   To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>>>   For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >> ---------------------------------------------------------------------
>> >>>>>>   To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>>   For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>   --
>> >>>>>   Olivier Lamy
>> >>>>>   Talend: http://coders.talend.com
>> >>>>>   http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >>>>>
>> >>>>>
>> >> ---------------------------------------------------------------------
>> >>>>>   To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>   For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>
>> >>>>
>>  ---------------------------------------------------------------------
>> >>>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>  For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>
>> >>>
>> >>>  ---------------------------------------------------------------------
>> >>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>  For additional commands, e-mail: dev-help@maven.apache.org
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message