Mark, There is no need to educate me on SVN semantics, I used it for quite a few years before I found git and abandoned it entirely. This is not about that.
There was an artifact with a name on a public repository free to be distributed as the public see fit under a specific name. Now there is a second one with the same name out there, in the wild. MUCH better to skip 31 and roll with 32 than to have two artifacts with different behaviours under the same exact name. Granted the chances of someone nabbing a copy in the mean time are low, but still, it's an unacceptable situation in my perfect little world, especially when it can be avoided simply by skipping 31 and using 32. It's not like the String the version is stored in has any limitations such as 9223372036854775807 for the signed 64 bit long. Although I doubt you'd run out even if you skipped 10, used one and used an unsigned short ;-) As for deleting tags from SVN being "perfectly fine", I couldn't disagree more. Not even slightly more. Any commit to an SVN tag is forbidden in my perfect little (dream) world where a name means exactly one thing and nothing more. Not even slightly more. SVN tags are a primitive thing simply meant to make it easier for the dev to remember from whence a version came, should they need to branch from it and do a fix, for example. There's really no point to SVN tagging at all, save that, as the mvn release plugin is quite happy to permanently brand your history with the fact that it did what it did, and that alone, with some patience (SVN is the definition of slow), and simple grep use is enough to expose where the releases happened over time. From those numerical revisions, you could then easily branch, dispensing with the expensive SVN tag operation entirely. However, this isn't the place for such a discussion, hence my not replying to Tom's previous comments. Bait taken, this time, though. I'm sure you didn't mean to patronise me, though, right? :-) Regards, Fred. On Wed, Jan 30, 2013 at 2:11 PM, Mark Struberg <[email protected]> wrote: > > > Hi Fred! > > This is absolutely no problem in SVN. Even deleting a TAG will not remove > it from the history! It is still there and can be checked out with the > revision. It's just not listed in the directory anymore... > > This is of course not the case for some other SCMs like e.g. CVS where you > would loose history, but removing a tag in SVN is perfectly fine! > > LieGrue, > strub > > > > > > >________________________________ > > From: Fred Cooke <[email protected]> > >To: [email protected] > >Sent: Wednesday, January 30, 2013 7:54 AM > >Subject: Re: [mojo-dev] [VOTE] Release mojo-parent version 31 and > mojo-sandbox-parent version 12 (take 2) > > > > > >Wait a second, did you guys delete the tag and re-tag? (or modify tag?) > :-o Is this normal codehaus practice? Or is it because I just crawled out > of bed and am very wrong/confused? > > > > > >On Tue, Jan 29, 2013 at 11:51 PM, Tony Chemit <[email protected]> > wrote: > > > >On Tue, 29 Jan 2013 23:50:34 +0100 > >>Tony Chemit <[email protected]> wrote: > >> > >>my +1 > >> > >>tony. > >> > >> > >>> Hi, > >>> > >>> I'd like to release version 31 of the mojo-parent and version 12 of > the mojo-sandbox-parent > >>> > >>> Diff between last release of mojo-parent: > >>> > https://fisheye.codehaus.org/browse/mojo/trunk/mojo/mojo-parent/pom.xml?r1=16245&r2=17891 > >>> > >>> m-surefire-p plugin and report version are now synch:) (thanks Anders > for this one!) > >>> > >>> A lots of updates were done ( > https://jira.codehaus.org/browse/MOJO-1898). > >>> > >>> There is also https://jira.codehaus.org/browse/MOJO-1722 fixed and > >>> https://jira.codehaus.org/browse/MOJO-1807. > >>> > >>> Note that m-compiler-p stays on version 2.5.1 since we do not need at > the moment incremental compilation stuff (our project are not multi-module). > >>> > >>> Surefire > >>> Staging Repositories: > >>> General: https://nexus.codehaus.org/content/groups/staging/ > >>> Exclusive: > https://nexus.codehaus.org/content/repositories/orgcodehausmojo-009/ > >>> (Staging) Site: > >>> not available > >>> SCM Tag: > >>> http://svn.codehaus.org/mojo/tags/mojo-parent-31 > >>> http://svn.codehaus.org/mojo/tags/mojo-sandbox-parent-12 > >>> > >>> [ ] +1 > >>> [ ] +0 > >>> [ ] -1 > >>> > >>> The vote is open for 72 hours and will succeed by lazy consensus. > >>> > >>> > >>> Cheers, > >>> > >>> tony. > >> > >>--------------------------------------------------------------------- > >>To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > >> > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
