On 30 January 2013 13:41, Fred Cooke <[email protected]> wrote: > 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. >
You do know that GIT tags are mutable too ;-) > > 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. The convention here is that until the artifacts have been pushed to central, delete as you see fit. Subversion tagging is just a convention.... your world has a different convention than ours... horses for carts > 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 >> >> >> >
