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 <[email protected]> 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 <[email protected]> > To: > Maven Users List <[email protected]>, > 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 <[email protected] <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: [email protected]<javascript: > ;> > > > For additional commands, e-mail: [email protected]< > javascript:;> > > > > > > -- > > > Baptiste <Batmat> MATHUS - http://batmat.net > > > Sauvez un arbre, > > > Mangez un castor ! nbsp;! <[email protected] <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: [email protected] > For additional commands, e-mail: [email protected] > >
