Dear Gil,
I took over this strategy from you, the current build of documents on macOS is
doing exactly the same. I even kept your comments from the script as pointers
in my script. This works very well but have the effect that ANY change of a
single document within that folder will trigger a SVN revision change. Hence my
question too Rony.
per aspera ad Astra…
Hälsningar/Regards/Grüsse,
ooRexx
oor...@jonases.se
> On 22. Dec 2022, at 14:58, Gilbert Barmwater <gi...@bellsouth.net> 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.
>
> One final thought: if this toolset is used to build the documents, then the
> rev. number and date could be saved in the properties file. If no entry
> exists, run the getdocrev() function and save the results in the properties.
> Otherwise use the properties. Manual editing of the properties file can
> "fix" false update information.
>
> FWIW, Gil
>
> On 12/22/2022 8:27 AM, Rony G. Flatscher wrote:
>> Sleeping over this revision problem in the context of the documentation
>> there is another problem with them in the case we must update the copyright
>> notes in the files: each file that gets changed and committed will get a new
>> revision which does not reflect the revision of the last change of the
>> documentation.
>>
>> Here an additional approach to solve this: if there is a file
>> ${book}/revision_info.txt (this file needs to be created by the script with
>> the revision information as the only content and can then be edited manually
>> from then on) then use its content for the revision information and do not
>> inspect the revisions of the individual documentation files. If that
>> ${book}/revision_info.txt is missing, then go ahead and try to figure out
>> the revision information with the current logic (and create
>> ${book}/revision_info.txt with the revision information).
>>
>> If one uses the current logic first (in addition will ignore the revision of
>> "Authors_Group.xml") - before updating the copyright information - and then
>> creates those ${book}/revision_info.txt files the revision information
>> remains the same until sometimes in the future the file gets updated (to run
>> the fallback logic in the future one would need to rename or delete
>> ${book}/revision_info.txt, such that the fallback logic takes effect).
>>
>> Enclosed the updated script (needs to go into tools).
>>
>> ---
>>
>> If this is o.k. for everyone I would use it to set EDITION to "2022.12.24"
>> (to distinguish it from the current) and have the revision information
>> created and appended to it, including creating revision_info.txt which I
>> would add to be committed as well (rerunning is almost instantaneous with
>> it).
>>
>> ---rony
>>
>> .. cut ...
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
