maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: how to make the SVN release process more robust
Date Mon, 05 Aug 2013 19:39:41 GMT
typically you go

$ mvn release:prepare release:perform -B

So there is maybe a 1 second window when somebody can mutate the tag
between the create and the checkout...

Now if you are doing release:perform a while after the release:prepare (the
tag is created only as the second last operation at end of the prepare step
- the final being checking in the development of next version poms) then it
could be a concern...

But that will always be an issue.... because you could have the case where
the machine with the release.properties has a hard disk failure before you
can run release:perform and as a result you loose the revision detail.

TL;DR for every safeguard you put in place (that is not a rule enforced on
the Subversion server) we can find a scenario that can work around your
safeguard... the solution is a rule enforced by the Subversion server that
only permits creation and deletion of tags and no modification to the tags
themselves (you need delete if you ever want to respin a release... if you
don't want to respin [your name could be sebb or fred :-P ] then don't put
a rule that permits deleting borked tags.


On 5 August 2013 18:14, Nathan Coast <nathan.coast@db.com> wrote:

> Classification: Public
>
> I'm not sure that will help our problem as tags remain mutable.  The tag
> checked out for release perform could still be corrupted.
>
>
>
>
> From:
> Stephen Connolly <stephen.alan.connolly@gmail.com>
> To:
> Maven Users List <users@maven.apache.org>,
> Date:
> 05/08/2013 18:00
> Subject:
> Re: how to make the SVN release process more robust
>
>
>
> The original behaviour was to tag the local working copy not the remote
> tree, so that you could release at any time without having to for e a
> "quiet" period on trunk.
>
> Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot
> recall
> which) made tagging from working copies for https based repositories
> difficult for users.
>
> Now that serf is the default transport, perhaps we can switch back to the
> old behaviour?
>
> On Monday, 5 August 2013, Baptiste MATHUS wrote:
>
> > Hi,
> >
> > Well, as this is actually something that the SCM itself allows, I would
> > consider just forbidding on my svn server.
> >
> > This might be an interesting evolution though to be able to enforce this
> at
> > the maven-release-plugin (though unlikely to happen often since the
> three
> > usual commits actually happen very close to each others).
> >
> > Cheers
> >
> >
> > 2013/8/5 Nathan Coast <nathan.coast@db.com <javascript:;>>
> >
> > > Classification: Public
> > >
> > > Hi all,
> > >
> > > As SVN tags are simply a convention overlayed on top of SVN
> directories,
> > > SVN tags are therefore mutable.  This opens the possibility that
> someone
> > > could inject code to a tag between the release:prepare and the
> > > release:perform phases.
> > >
> > > This would mean that the code checked out during release perform phase
> > > could be different from the code which was originally tagged.
> > >
> > > To close this potential loophole, I'm considering this solution:
> > > 1)  Modify the behaviour within
> > > org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to
> > > return the tag revision number via TagScmResult
> > > 2)  Write the result to release.properties
> > > 3)  Utilise the revision number within the checkout command (tag plus
> > > revision#)
> > >
> > > Does anyone have any alternate suggestion for how to solve this?
> > >
> > > Regards,
> > > Nathan
> > >
> > >
> > >
> > >
> > > ---
> > >
> > > This e-mail may contain confidential and/or privileged information. If
> > you
> > > are not the intended recipient (or have received this e-mail in error)
> > > please notify the sender immediately and delete this e-mail. Any
> > > unauthorized copying, disclosure or distribution of the material in
> this
> > > e-mail is strictly forbidden.
> > >
> > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> > > additional EU corporate and regulatory disclosures.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org<javascript:
> ;>
> > > For additional commands, e-mail: users-help@maven.apache.org<
> javascript:;>
> > >
> > > --
> > > Baptiste <Batmat> MATHUS - http://batmat.net
> > > Sauvez un arbre,
> > > Mangez un castor ! nbsp;! <users-help@maven.apache.org <javascript:;>>
> >
>
>
> --
> Sent from my phone
>
>
>
>
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> additional EU corporate and regulatory disclosures.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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