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