Git tags vs SVN tags and some edge cases

[Glen Barber]

I was asked to send and email about this as something about which we
need to be aware when retaining history during the official final
conversion from SVN to Git.

There are four known anomalies (naturally, all of which are mine) with
SVN tags that may not translate well when the conversion to Git is done.
Here follows said known anomalies and the reason for their existence:

1) 11.0-RELEASE and the case of the real RELEASE - 11.0-RELEASE-p1:
   When the initial builds for 11.0-RELEASE were done, there was still
   an outstanding issue with the freebsd-update(8) utility that I was
   under the impression had already been fixed, but it had not.  Since
   11.0-RELEASE was already available on the download mirrors and had
   already become actively used, the original ISOs were renamed and
   following the fix to the issue blocking the release, we opted to
   release 11.0-RELEASE as 11.0-RELEASE-p1, retaining the original
   release/11.0.0 tag and re-tagging the real official release as
   release/11.0.1.

2) 10.0-RELEASE and the case of missing build fixes:
   During the 10.0-RELEASE cycle, the release/10.0.0 tag was created
   from r260664, however there were several changes to fix various parts
   of the build, committed as r260788.  The real 10.0-RELEASE tag was
   created from r260788 to incorporate said fixes.  So, this tag was
   deleted and recreated. [1] [2] [3]

3) 9.3-RELEASE and the case of the wrong source revision:
   The original 9.3-RELEASE tag, release/9.3.0, was created from r268519
   by mistake, when it should have been created from the commit that
   changed the name to -RELEASE (r268512).  So, this tag was deleted and
   recreated. [4] [5] [6]

4) 8.4-RELEASE and the case of the change-in-a-tag wrong commit:
   The original commit for 8.4-RELEASE included a change to
   sys/conf/newvers.sh to rename from -RC3 to -RELEASE, which was wrong
   (r250625).  The release/8.4.0 branch was deleted in r250629 and
   recreated from r251258 (not a typo) after the erroneous commit had
   been discovered some time later.

[1] https://lists.freebsd.org/pipermail/svn-src-release/2014-January/000007.html
[2] https://lists.freebsd.org/pipermail/svn-src-release/2014-January/000008.html
[3] https://lists.freebsd.org/pipermail/svn-src-release/2014-January/000009.html
[4] https://lists.freebsd.org/pipermail/svn-src-release/2014-July/000010.html
[5] https://lists.freebsd.org/pipermail/svn-src-release/2014-July/000011.html
[6] https://lists.freebsd.org/pipermail/svn-src-release/2014-July/000012.html
[7] https://lists.freebsd.org/pipermail/svn-src-release/2013-May/000003.html
[8] https://lists.freebsd.org/pipermail/svn-src-release/2013-May/000002.html
[9] https://lists.freebsd.org/pipermail/svn-src-release/2013-June/000005.html

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20200421/4c0a9a51/attachment.sig>