Updating the copyright date is another of those items that should have taken place before creating the branch. In my opinion, it is useless to include an SVN revision number in a release version of the documentation. Once the release ships, that branch is frozen, so the SVN revision number is essentially meaningless. That version of the docs will never be anything else. Any new version will just be part of another release update, so it really is uniquely identifiable by the release number information. I have no objections to also including a date with the version information, but again, there will be no other version associated with the current release number.
Rick On Thu, Dec 22, 2022 at 9:36 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > On 22.12.2022 14:58, Gilbert Barmwater wrote: > > Back in July (seems like years ago), I modified the ooRexx version of the > document build tools. As part of that effort, I did some work to have > docprep.rex modify the VERSION and EDITION ENTITIES "on the fly" (Note only > in the working copy). Have a look in the tools/bldoc_orx folder at > docprep.rex around line 130. You will se that it uses a function > getdocrev() which is in a separate file in the same folder: getdocrev.rex. > It uses the SVN log command to determine the revision number and the > revision date for the document name supplied as an argument. It is well > documented so a little time reading it will show how it works. This is just > for additional information as we consider possible solutions. Please ask > any questions that you may have. > > Looked up your code (was not aware of that at all) and looked into > getdocrev.rex which uses the "svn log" command with "-l 1". This will > return the latest log entry in the form (used the current > "docs/branches/5.0.0/rexxapi"): > > ------------------------------------------------------------------------ > r12568 | orexx | 2022-12-22 13:41:55 +0100 (Do., 22 Dez 2022) | 1 line > > add authors who committed as of late > ------------------------------------------------------------------------ > > As you can see the revision and date has today's value. The reason being > that I updated the Author_Group.xml file by adding Erich. > > Each time "rexxapi.ent" gets changed by your tool will cause a commit to > at least set the log to that date, irrespectable of having changed any of > the documentation xml files. > > --- > > In order to figure out the last change to the documentation files > themselves is inspecting the xml files in rexxapi/en-US and gathering the > newest commits from them. However, whenever rexxapi/en-US/rexxapi.ent > changes or rexxapi/en-US/Author_Group.xml changes they would mostlikely be > the latest commit. > > The documentation files themselves might been committed longer ago. If I > understand the request correctly, then we want the latest revision of the > documentation files (the xml files in rexxapi/en-US) instead. Doing so > would bring up commit r12507 as of 2022-09-02 for the rexxapi book, not > r12568 as of today. > > The utility svnListRevisions.rex that I committed two years ago would > allow for gathering all commit information of all files in rexxapi/en-US > and return an array where each commit is a Rexx object that can be > interrogated for these commit-revision and commit-date attributes (and also > for the author info) for each file. It uses "svn -r HEAD --xml > --incremental list". > > --- > > Now another problem shows up: if we update the copyright year to the > latest year in all those documentation xml files (not sure whether we are > supposed to do that), then the logs for all those xml files will get > updated on the next commit to reflect the change of the copyright > information, not the content of the documentation file. > > Hence coming up with the idea of placing the "real" revision information > right in the rexxapi directory as a text file (that can also be manually > changed). This allows one to check out all books revision information that > is related to changing the documentation xml files. As long as copyright > changes, or changes in rexxapi.ent or Author_Group.xml take place the > content of "rexxapi/revision_info.txt" will be used for setting the > revision information if employing "updateEntityValues.rex" which will > update "rexxapi.ent" accordingly. > > In the case that a true content change gets made to any documentation xml > files the author could change "rexxapi/revision_info.txt" manually. > > Alternatively, if we know that the content of any documentation xml file > got changed we could eventually run "updateEntityValues.rex" with the "-r" > switch for that book, but need previously to remove > "rexxapi/revision_info.txt" such that svnListRevisions.rex gets employed to > get the latest commit from the documentation files, which then will cause > "rexxapi/revision_info.txt" to be created with that revision information. > > ... cut ... > > ---rony > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
