On 22.12.2022 17:52, Gilbert Barmwater wrote:
Sorry I wasn't more clear in my final comments. If one could determine the "real" dates, probably
manually, and update and "commit" the values in the *.ent files, then the "automated" mechanism in
docprep.rex could be removed/bypassed. As you have the data in the revision_info.txt files, all
it would take is to go through them, update the *.ent files and commit the changes. Then the code
in docprep.rex could be commented out. Builds would then have the correct revision number and date.
OK. Then I would add and commit those files such that they become visible via svn and available in
branches/5.0.0 and trunk.
---
Still, there is one open question: Rick's comment was about not supplying this revision information
on the official release as revision information of the documentation for that point release would
not make sense as the documentation for that particular release will never change, which makes sense.
If that is not objected, I would go ahead and set the release ent files in branches/5.0.0 to not
show the documentation revision information.
Once the release version of the documentation gets copied over to trunk, I would change the
ent-files in trunk to carry the revision information (and set trunk's year to 2023, the version to
"5.1.0", the edition to "beta (rev-infos)").
---rony
On 12/22/2022 11:32 AM, Rony G. Flatscher wrote:
On 22.12.2022 16:17, Gilbert Barmwater wrote:
... cut ...
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.
Indeed.
Nevertheless, in the case of changing the copyright dates the revision being picked up would not
reflect the revision of the last change in any of the documentation from then on, unfortunately.
(Practically every file contains the copyright 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.
svn log currently does not reflect the "real" change as of my commit today when changing the
"Author_Group.xml".
Again, the svn log would not reflect the last "real" change once copyright updates take place.
(Just noticed that there are copyright changes that get applied to non-xml files, like Makefile
or config files as well.)
It just has been the case that we did not have a release for a long time such that the svn log
would reflect the last real change as long as the ent files did not get committed.
---
So, if we wish to carry the revision of the last "real" change we need to resort to some other
mechanism.
As by chance we currently have these revisions and dates (currently I have them stored in
revision_info.txt files in the appropriate book subdirectories and created a zip-archive of them).
So I would suggest to use these "${book}/revision_info.txt" files (their first line) for docprep
instead. This makes the revision information indpendent of svn log.
Whenever the real documentation changes its "${book}/revision_info.txt" should
be updated manually.
If an author forgets to do that one could then do the following as long as now bulk change of the
copyright information took place: delete or rename the "${book}/revision_info.txt" and run
'updateEntityValues.rex -e "editionInfo" -r 99999 ..' (this will recreate missing
"${book}/revision_info.txt" from the latest revision (it will not touch existing
revision_info.txt files), ignoring the ${book}/en-US/${book}.ent and
${book}/en-US/Author_Group.xml files).
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
