Hi Nathan, > I'm not sure that will help our problem as tags remain mutable. The > tag checked out for release perform could still be corrupted.
As I asked before: who is doing this "corruption"? If you have committers capable of doing that, they could absolutely hose your repository in all sorts of ways. It's a much bigger problem than just the maven-release-plugin. That's not to say your proposed changes wouldn't make maven-release-plugin more robust -- it just seems like an unwinnable battle. Better to go Baptiste's very sensible route of locking down the server on the server-side. -Curtis P.S. SVN is certainly not unique in having mutable tags. Git's tags are mutable too: just force push over top the old one. And any VCS having immutable tags would be a real PITA, IMO. On Mon, Aug 5, 2013 at 12:14 PM, 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] > >
