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.
Gil
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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
