Hello, I think svn/git are most interesting, as AFAIK all core-plugins reside in these SCMs :-).[1]
Being able to easily review the code diff between several takes or releases has a value of it's own IMO. With websvn, gitweb or github e.g., it is quite trivial to create a link which shows the complete diff/patch between two tags/branches. To include such a link in the vote mail would be great (fisheye/viewcvs do *not* have this ability unfortunately), at least a command line reproducing the patch could help. It is much more effort, when every reviewer does this work on her own, let alone when tags are mutable as they are in the current process, where you have to scan the log for the correct revisions/hashes. Regards Mirko [1] People still forced to use CVS or Sourcesafe should probably just look for a new job or when they are the ones responsible for this a good shrink ;-). -- Sent from my mobile On Jun 29, 2013 3:30 AM, "Chris Graham" <chrisgw...@gmail.com> wrote: > Moreover, the discussion is very SVN/GIT centric. The release plugin and > continuum (as far as I know) are the primary users of the SCM api. The > entire scm api is an abstraction layer that is very cvs/svn centric (for > historical reasons) but an abstraction layer all the same, and abstraction > layers tend to the lowest common denominator (they have too). > > So as the "Do we respin version nos/tags" thread summarized, what is good > practice for one may not be for another. So, just like life, it's full of > comprimises. > > If we included AccuRev, ClearCase and Jazz, for example, into this thread, > then we'd have (probably) an entirely different view, based around what > those SCM's either could or could not do. (For example, Jazz can not delete > it's tags from the cli, only from the full Eclipse GUI or Web clients - so > that it not automatable. But the svn provider does not delete tags either, > so there may always be some manual cleanup involved). > > As it stands, I don't see the need to include the rev no in the email, as > the tag that has been created, that we are voting on, has it's own revision > no, and is easily found, as is the path. > > If the vote fails, the necessary changes are made, the same tag, with a > different revision no is used. If the vote passes, the tag remains > permanent. > > I see little value in documenting the failed releases. You will always be > able to trawl through these email lists and svn history to retreive the > intermediate details, should you ever need them. > > -Chris > > > > On Fri, Jun 28, 2013 at 10:21 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Friday, 28 June 2013, Fred Cooke wrote: > > > > > For git the unique hash is sufficient, you don't really need the tag at > > > all, they simply point to the unique hash (or another tag, in a chain). > > If > > > Git was the SCM of choice, I'd use RCX tags, and then not retag for > > final, > > > but rather point the final tag AT the last, accepted RC tag. > > > > > > For example > > > > > > artifact-RC1 >> 1234567890ABCDE > > > artifact-RC2 >> ABCDE1234567890 > > > artifact-RC3 >> 12345ABCDE67890 > > > artifact >> artifact-RC3 (yes this is possible! and is correctly > resolved > > > to the hash pointed to by the final chain-link) > > > > > > And how exactly do we bake the hash into the Pom? > > > > We need to know what we are baking into the Pom *before* we can commit > the > > Pom > > > > So in the GIT world, we need to bake a tag into the Pom as we cannot > > predict the hash. > > > > In the Subversion world, we need to bake a tag without revision into the > > Pom as we cannot predict the revision we will get when we do commit. > > > > I am fine with saying for GIT *votes* the hash of the tag should be > > included in the vote email, but pushing the tag at the time of the vote I > > see as a bad plan (unless we decide to change the tag naming convention) > > > > Subversion does not let us avoid committing the tag, so in that case I am > > fine with saying in the vote email tag@1234342 > > > > But I don't see (given the way the version numbering vote went) why we > need > > to do anything other than the above 1 small change to the vote emails.... > > And keep in mind that given that SCM is just a convenience, even that is > > not strictly necessary... It is the -src.tar.gz that we are voting on... > > Everything else is just a convenience > > > > > > > > > > If I were forced (at gun point) to use SVN again, I'd not create real > > > SVN-tags, I'd modify my tooling to either add SVN meta data linking > name > > > and revision number and path or do the same in a plain text file(s) > > > somewhere in the repo. The entire SVN cp thing leaves me feeling ill. > SVN > > > mv makes me want to cry like a girl. From the help info: > > > > > > Note: this subcommand is equivalent to a 'copy' and 'delete'. > > > > > > > > > > If only file systems were this good! :-p > > > > > > In terms of current SVN usage, the "SVN mv" command is probably a good > > > choice, as already discussed. You could argue that a "cp" would be > > better, > > > but this creates wholesale duplication, which is never good. > > > > > > Fred. > > > > > > On Fri, Jun 28, 2013 at 12:35 PM, sebb <seb...@gmail.com> wrote: > > > > > > > The re-use of tags is a side-issue to this thread, though I'm glad to > > > > see some support for using immutable tags, whatever route is chosen > > > > Please start a new thread to continue that discussion. > > > > > > > > The vote e-mail must have the revision and tag name/trunk URL in it > > > > else it is not complete. > > > > > > > > Just as Maven insists on GAV - where V=version - a unique SVN > > > > coordinate requires the revision and the tree segment selector (e.g. > > > > tag). > > > > I don't know what Git needs - I suppose it may depend on whether > > > > multiple components are part of the same Git instance. > > > > > > > > But whatever - as it stands, the current vote e-mail is > > > > **incomplete**; it does not provide sufficient information for the > > > > candidate to be properly evaluated. > > > > The information needs to be present both for current and historical > > use. > > > > > > > > On 28 June 2013 10:09, Arnaud Héritier <aherit...@gmail.com> wrote: > > > > > +1 to change our tags convention if it solves this issue by > avoiding > > to > > > > > reuse tag names to give a better visibility from where a release > was > > > done > > > > > > > > > > > > > > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold < > > > > > kristian.rosenv...@gmail.com> wrote: > > > > > > > > > >> This suggestion is much like what we came up with the last time > > > > >> we discussed this - about 3 weeks ago. > > > > >> > > > > >> This behaviour is simple to achieve without a single line > > > > >> of change; the release plugin already asks for a SCM tag name > > > > >> distinct from the version number. (we *could* add some kind > > > > >> of support for an explicit convention, we could even add a > > scm-lookup > > > > >> to auto-roll forward on subsequent takes). > > > > >> > > > > >> Now I've been trying to think if there's a sensible convention > > > > >> that could be established that would allow us to > > > > >> simply *keep* the tag name of the accepted version > > > > >> without re-pushing another tag after release (and, since the tag > > > > >> name can be etched into the pom of the released artifact, there > > > > >> should be no real reason for confusion). > > > > >> > > > > >> I've been thinking about a *tagging* convention along the lines > > > > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2, > > > > >> maven-xx-plugin-2.3.2#3..." > > > > >> > > > > >> Effectively we would delete #1 and #2 and keep the #3 tag, since > > this > > > > >> vote passed on take 3. > > > > >> > > > > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of > the > > > > >> released 2.3.2 version. > > > > >> > > > > >> This is mostly a policy change on tag naming, we could implement > > this > > > > >> without a line > > > > >> of code change. Since both svn and git essentially have flawed tag > > > > >> handling it makes sense to do a change like this. > > > > >> > > > > >> Kristian > > > > >> > > > > >> 2013/6/28 Ralph Goers <ralph.go...@dslextreme.com>: > > > > >> > Can you provide the steps required to get the release plugin to > > work > > > > >> this way? > > > > >> > > > > > >> > Ralph > > > > >> > > > > > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote: > > > > >> > > > > > >> >> Hello, > > > > >> >> > > > > >> >> this seems to be the most popular discussion, so another 2 > cents: > > > > >> >> - Today I read the man page of git-tag again. > > > > >> >> - It states very clearly you should never reuse tags, because > > > unlike > > > > is > > > > >> the > > > > >> >> case with subversion, once a git tag is out in the wild (and > > > pushing > > > > to > > > > >> >> git-wip is the jungle here), everyone who has fetched the tag > > would > > > > >> have to > > > > >> >> delete it *manually* from her copy, otherwise it will point to > > the > > > > wrong > > > > >> >> hash eternally. > > > > >> >> > > > > >> >> Another approach: > > > > >> >> - Always attach the rc-number to the tagname, e.g. > > > maven-foo-2.16rc1, > > > > >> but > > > > > > > > > -- > > Sent from my phone > > >
