maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
Subject Re: how to make the SVN release process more robust
Date Mon, 05 Aug 2013 17:23:40 GMT
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 <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