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
