keep Subversion version # capability? On stupidity
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.
I did a bit of spelunking because I thought I remembered writing that code,
and indeed,
https://github.com/TEIC/TEI/commit/0e10f2baa211cf86e9a898389bc26c2df92ea9fb,
way back in 2014! I was just starting the project of convincing Council to
move to Git from Subversion :-).
I think a) there's no need to keep the svn code, and b) we might think
about cleaner ways to do it, because it intentionally makes git imitate the
svn info XML format (so that it wouldn't make a difference which version
control system you used).
Hugh
On Sat, Feb 13, 2021 at 10:28 AM Bauman, Syd
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.
_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
(a) Well, if you the author think there’s no need to keep it, I’m convinced. (I was pretty close to convinced already. :- ) (b) Way ahead of you, mate. Plan is to make the file potentially more useful, have it use the TEI namespace (because the code that interrogates it already has xpath-default-namespace=TEI), and call it repo_info.xml, instead. E.g., here is my current local version: <?xml version="1.0" encoding="UTF-8"?> <application xmlns="http://www.tei-c.org/ns/1.0" ident="git" version="2.25.1" when="2021-02-12T16:27:46-05:00" n="381fd17f6"> <ab type="status"> On branch sydb-improve_expand Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: Makefile no changes added to commit (use "git add" and/or "git commit -a") </ab> </application> This means that the expansion code could just use /application/@n for the commit #, for example. (What it does now is somwhat more convoluted.) I am not at all sure why the leading space in front of “</ab>” is missing, but I also don’t think it is worth much of my time to figure out. ________________________________ I did a bit of spelunking because I thought I remembered writing that code, and indeed, https://github.com/TEIC/TEI/commit/0e10f2baa211cf86e9a898389bc26c2df92ea9fbhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FTEIC%2FTEI%2Fcommit%2F0e10f2baa211cf86e9a898389bc26c2df92ea9fb&data=04%7C01%7Cs.bauman%40northeastern.edu%7C5ce8c3ed2fc24e27e39808d8d0457397%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637488344003628090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TIjRcit%2FqtNRJ7T5mgCJ26g9UPnGBPSMOEPwTK6aYK8%3D&reserved=0, way back in 2014! I was just starting the project of convincing Council to move to Git from Subversion :-). I think a) there's no need to keep the svn code, and b) we might think about cleaner ways to do it, because it intentionally makes git imitate the svn info XML format (so that it wouldn't make a difference which version control system you used).
Hi all, On 2021-02-13 7:28 a.m., Bauman, Syd wrote:
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.
I'm fine with being called stupid and quite accustomed to it -- my father's nearest approach to a compliment was "It appears that you are not quite as stupid as we have hitherto assumed" -- but I don't think I actually do use <text> as a child of <teiCorpus> in any of my projects. Did I say that I did at some point, or did I just say that I could imagine reasons that someone might want to do it? On the changeover to GitHub, Peter and Hugh and others did lots of sterling work, and also don't forget the really impressive stuff Raff did to port over the issue history. :-) Cheers, Martin
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.
_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca
Ha! My father would say “for a smart kid that was pretty dumb” or (essentially the opposite) “guess you’re not as stupid as you look” — although he always said these things with a smile. No need to fret the details of <text>-as-child-of-<teiCorpus>, just know that I am against it strongly enough that I think we should (as Hugh says) try to put the toothpaste back in the tube. In the Sourceforge → GitHub project, I do remember that others including Hugh and Raff were involved, but had mis-assigned credit for the great History Reconstruction. Thank you for the correction! (And, again, kudos to all of you who pulled that off.) ________________________________ I'm fine with being called stupid and quite accustomed to it -- my father's nearest approach to a compliment was "It appears that you are not quite as stupid as we have hitherto assumed" -- but I don't think I actually do use <text> as a child of <teiCorpus> in any of my projects. Did I say that I did at some point, or did I just say that I could imagine reasons that someone might want to do it? On the changeover to GitHub, Peter and Hugh and others did lots of sterling work, and also don't forget the really impressive stuff Raff did to port over the issue history. :-)
participants (3)
-
Bauman, Syd -
Hugh Cayless -
Martin Holmes