svn commit: r495383 - in head/java: . wildfly16 wildfly16/files
Alexey Dokuchaev
danfe at freebsd.org
Thu Mar 14 16:38:25 UTC 2019
On Thu, Mar 14, 2019 at 05:29:40PM +0100, Torsten Zuehlsdorff wrote:
> On 14.03.19 17:19, Alexey Dokuchaev wrote:
> > On Wed, Mar 13, 2019 at 06:17:19PM +0100, Kurt Jaeger wrote:
> >>>> Log:
> >>>> New port: java/wildfly16
> >> [...]
> >>> Its name suggests it should've been repocopied from one of the earlier
> >>> versions but it was not, why is that?
> >>
> >> I missed it, that is common for arkane rules.
> >
> > There's nothing arcane about repocopies Kurt. I'm honestly surprised
> > why people make this mistake again and again. When you resurrect a
> > port you make a repocopy. When you spin-off a new branch based on a
> > previous version you make a repocopy (like you've added a new wildfly
> > port, how could you not have noticed that there are a handful of ports
> > thereof already?):
> >
> > $ grep wildfly /usr/ports/java/Makefile
> > SUBDIR += wildfly10
> > SUBDIR += wildfly11
> > SUBDIR += wildfly12
> > SUBDIR += wildfly13
> > SUBDIR += wildfly14
> > SUBDIR += wildfly15
> > SUBDIR += wildfly90
> >
> > Upstream renames their software, you make a repocopy, etc.
>
> A rename should be a "svn mv" instead of "svn cp"? Or am i mistaken?
Well yeah, I didn't go to the very details. However, svn move is
equivalent to an svn copy followed by svn delete*.
./danfe
*) http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.move.html
More information about the svn-ports-head
mailing list