Hey all. Two things. First just wanted to clarify that when I said “because it’s stupid” in reference to <text> as a direct child of <teiCorpus>, I was trying to express that it was inappropriate and careless of us to ever let <text> slip into the content model
of <teiCorpus> in that position (which happened in 2016-02). I am (as y’all can probably tell) somewhat annoyed with myself for not noticing this as a problem when it came up then. I was not calling users (like Martin and Janelle, among others) who make use
of this perfectly valid facility stupid.
My current annoyance, though, is some horrible code. Thus I want input on what to do with P5/repodate.xml. This is an untracked file generated by the Makefile during the P5 build process and read by the P5/Utilities/expand.xsl program. That program changes
the <?insert date?> PI found in P5/Source/guidelines-en.xml (and in P5/Source/guidelines-fr.xml) and thus in p5.xml into the date the GLs were built, and changes the <?insert revision?> PIs into the git commit number, etc.
This whole system is made quite a bit more complicated by the fact that the code is designed to work whether the version control system we use is Subversion or git. My instinct is that it is no longer useful to maintain the code that worries we might be using
Subversion rather than git. We have not been using Subversion for roughly 5 years,[1] and I do not see us ever going back to it. Sure, GitHub the service is a company and may fold, but git the command is not going away. Something better may come along, and
we may switch in the future, but that means re-working all this code, anyway.
The only reasonable concern that floats through my tiny brain is that maybe we need this code in case someone uses the current build system to try to generate a very old copy of the
Guidelines that dates back to the pre-git days. But I do not have any reason to believe that either anyone would use the modern Makefile to build an ancient copy of the
Guidelines (you would use the build system that came with that revision), or that there would be any hope of success even if this code for handling Subversion revision numbers was left in place.
So does anyone think we should leave the Subversion code in there? Going once …
P.S. Given that we are in the refrigeration period, I will be doing this in a separate branch and leave it to others whether to merge it before or after release. It should have absolutely no effect on the output at all. (And if anything goes wrong, would be
very easy to spot by just checking the output of PIs.)
Notes
[1] My vague recollection is that the changeover from Subversion in Sourceforge to git in GitHub was masterfully handled by Peter Stadler in 2015 or 2016.
_______________________________________________