See below...
On 12/22/2022 9:35 AM, Rony G. Flatscher 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.
You missed my comment about the change only being made to the "working
copy", hence no "commit" ever takes place and the source in svn is
unchanged.
---
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 ...
I think we are missing the intent of the ENTITY entries for each
document. If each author who makes a "real" change to a book would go
back after doing the "commit" and update the relevant ENTITY values and
do another commit, the revision information would not need any further
changes. Yes, the second commit changes the revision but it is not a
change to the document itself and so it can be ignored. Unfortunately,
developers are either unaware of this need or it is just an easy thing
to forget. If it were up to me I would use the svn log command for each
book to determine the revision number and date of the last "real" change
and then update and commit the ENTITY values. The build will then not
need to do anything else.
---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
