I applied this patch without problems (from a Mac) using SVN. It seem Rony (?) did the same, I hope it works out.
I do not know what is causing Jon’s problems Hälsningar/Regards/Grüsse, ooRexx [email protected] > Am 02.11.2025 um 15:00 schrieb Rick McGuire <[email protected]>: > > When I run svn info on my checked out docs tree if shows i used > > https://svn.code.sf.net/p/oorexx/code-0/docs/trunk > > On Sun, Nov 2, 2025 at 8:40 AM Sahananda <[email protected] > <mailto:[email protected]>> wrote: >> Hi Rony, >> >> I'm sorry to be more trouble. >> >> When I try to checkout from >> https://sourceforge.net/p/oorexx/code-0/HEAD/tree I get the following error: >> >>> Checkout from https://sourceforge.net/p/oorexx/code-0/HEAD/tree, revision >>> HEAD, Fully recursive, Externals included >>> Unable to connect to a repository at URL >>> 'https://sourceforge.net/p/oorexx/code-0/HEAD/tree' >>> The server at 'https://sourceforge.net/p/oorexx/code-0/HEAD/tree' does not >>> support the HTTP/DAV protocol >> >> looking at the sourceforge help I see that I need to prefix the url with >> svn+ssh, and then I get a different error >> >>> Command: Checkout from >>> svn+ssh://https://sourceforge.net/p/oorexx/code-0/HEAD/tree, revision HEAD, >>> Fully recursive, Externals included >>> Error: Unable to connect to a repository at URL >>> Error: 'svn+ssh://https/sourceforge.net/p/oorexx/code-0/HEAD/tree >>> <http://sourceforge.net/p/oorexx/code-0/HEAD/tree>' >>> Error: To better debug SSH connection problems, remove the -q option from >>> 'ssh' in the >>> Error: [tunnels] section of your Subversion configuration file. >>> Error: Network connection closed unexpectedly >>> Completed!: >> >> Experimenting showed that I could include my username at the end of the url >> thus: >> svn+ssh://https://sourceforge.net/p/oorexx/code-0/HEAD/tree--username=sahananda >> but this brought back the same error. Although now I am asked for my >> password three times. >> >> I let Sourceforge generate a checkout url for me and it came up with >> svn+ssh://[email protected]/p/oorexx/code-0/main/trunk >> <http://[email protected]/p/oorexx/code-0/main/trunk> >> but again this brought back the same error. >> >> Combining the url you suggested with the one SF created for me I get >> svn+ssh://[email protected]/p/oorexx/code-0/HEAD/tree >> <http://[email protected]/p/oorexx/code-0/HEAD/tree> >> : >> Looking at my subversion config file, every line is commented. However in >> the [tunnels] section there is a line >>> # ssh = $SVN_SSH ssh -q -- >> and I am going to try >> ssh = $SVN_SSH ssh -- >> >> Following this, trying a checkout results in three consecutive console >> windows flashing up without content (& not accepting content), I assume they >> replace the prompts for my credentials and then after sitting there for 40 >> seconds, they timeout. >> >> I've run out of time to look at this today, but if anyone has dealt with >> this, please suggest remedies. >> >> >> Jon >> >> On Sun, 2 Nov 2025 at 11:15, Rony G. Flatscher <[email protected] >> <mailto:[email protected]>> wrote: >>> Dear Jon, >>> >>> first of all: thank you *very* much for taking this on! >>> >>> On 01.11.2025 22:46, Sahananda wrote: >>>> I'm willing, BUT: >>>> >>>> I have applied the patch 325 successfully to my working copy, but when I >>>> try to commit docs/trunk I receive the following error. >>>> >>>>> Command: Commit to svn:// <>svn.code.sf.net/p/oorexx/code-0/docs/trunk >>>>> <http://svn.code.sf.net/p/oorexx/code-0/docs/trunk> >>>>> Error: Commit failed (details follow): >>>>> Error: Authorization failed >>>>> Completed!: >>>> >>>> I am signed in in the usual way, and have committed items from this >>>> userid before (though not recently, not from this working copy, not from >>>> this laptop, not with this install of Tortoise and not to docs). >>> Not knowing Tortoise too well (using Apache's command line svn package >>> myself), there is not much, I could contribute with respect to Tortoise. >>> >>> However, it does make a difference how you check out the ooRexx project >>> from Sourceforge! There are URLs for anonymous check out, with the >>> consequence that one cannot easily update trunk (if at all, not sure). >>> However, I have always been successful when checking out the ooRexx project >>> using the read-write version from >>> <https://sourceforge.net/p/oorexx/code-0/HEAD/tree/> >>> <https://sourceforge.net/p/oorexx/code-0/HEAD/tree/>: >>> >>> >>> >>> <11i7mzT8uxD7sZ0B.png> >>> >>> >>> >>> So maybe the solution is to check out the ooRexx-project with that >>> particular URL (just change the username to your username) and then >>> committing works from Tortoise on your current machien? >>> >>> >>> >>>> There is a button for 'Retry as different user' and pressing it I get a >>>> credentials dialog in which I enter my sourceforge signon; but then get >>>> the same error message. >>>> >>>> I am an admin on the sourceforge project with update, admin & create >>>> permissions >>>> >>>> I also tried just committing the individual changed files. No luck. >>>> >>>> I do remember that when I committed in the past I used to get three >>>> consecutive Login Dialogs from Tortoise, but now it does not even ask for >>>> my credentials when doing a commit. >>>> >>>> In case Tortoise had cached a bad password for me, I deleted the only file >>>> in %APPDATA%\Subversion\auth\svn.username, but that made no difference. >>>> >>>> Sorry to continue this already long thread, but I don't know where to take >>>> this now. >>> You *really* did almost everything possible, wow! >>> >>> Hopefully the read/write URL can solve the problem! >>> >>> Best regards >>> >>> ---rony >>> >>> >>> >>> >>>> >>>> On Sat, 1 Nov 2025 at 17:05, Rony G. Flatscher <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> Dear Jon, dear P.O., >>>>> >>>>> trying to follow the agreed-upon procedure. >>>>> >>>>> Here are three of Jospe Maria's doc patches that I looked at and which >>>>> look o.k.: >>>>> >>>>> <https://sourceforge.net/p/oorexx/documentation/325/> >>>>> <https://sourceforge.net/p/oorexx/documentation/325/> >>>>> <https://sourceforge.net/p/oorexx/documentation/351/> >>>>> <https://sourceforge.net/p/oorexx/documentation/351/> >>>>> <https://sourceforge.net/p/oorexx/documentation/352/> >>>>> <https://sourceforge.net/p/oorexx/documentation/352/> >>>>> Could you please be so kind as to process them? Thank you in advance for >>>>> your help! >>>>> >>>>> --- >>>>> >>>>> Just a general remark about Josep Maria's patches: he has an incredible >>>>> commandment of the ooRexx syntax acquired as can be seen by looking at >>>>> his Unicode-TUTOR ooRexx tool (https://github.com/JosepMariaBlasco/TUTOR) >>>>> and his rexx-parser (https://github.com/JosepMariaBlasco/rexx-parser) >>>>> project. Therefore, I would expect that all doc patches are correct. If >>>>> any of the committers would object to Josep Maria's doc bug reports, then >>>>> they probably would have done so. Personally, I have yet to see a >>>>> documentation-related bug report from him that is incorrect. >>>>> >>>>> Therefore, I think you can apply Josep Maria's documentation patches >>>>> without waiting for a committer to o.k. them. >>>>> >>>>> Also you could mostlikely resolve most of Josep Maria's documentation >>>>> related bug reports without his patches, as you are very knowledgeable >>>>> ooRexx programmers yourselves and therefore are able to assess the bug >>>>> reports! (Even if you do not think so! :) ) >>>>> >>>>> Best regards >>>>> >>>>> ---rony >>>>> >>>>> >>>>> >>>>> On 29.10.2025 12:36, Sahananda wrote: >>>>>> Hi Rony, >>>>>> >>>>>> I don't think that I made myself clear in my suggestion. Just for >>>>>> clarity: I was just noting that a full list of committers could be >>>>>> retrieved by opening the drop-down of the Owner field on the tracker >>>>>> items. >>>>>> Anyway, that doesn't matter. >>>>>> >>>>>> Your suggestion that promotions are approved by a request on the >>>>>> developers list specifying the tracker numbers works for me(+1). >>>>>> >>>>>> If that's ok with P.O. and anyone else who might join in the effort, >>>>>> let's go with that! >>>>>> >>>>>> thanks, >>>>>> >>>>>> Jon >>>>>> >>>>>> On Tue, 28 Oct 2025 at 10:05, Rony G. Flatscher <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>>> On 27.10.2025 22:18, Sahananda wrote: >>>>>>>> I think that if rather than +1 if you (or another committer) added a >>>>>>>> comment 'OK to promote' that would be clearer. >>>>>>>> We would know they were a committer because their sign-on would appear >>>>>>>> in the Owner drop down on the ticket. >>>>>>> The Owner field can be changed by committers. >>>>>>> >>>>>>> How about posting the links to the documentation tracker items that are >>>>>>> "OK to promote" in this developer list? >>>>>>> >>>>>>> This would serve two purposes: >>>>>>> >>>>>>> it gives an overview and easy access to the referred to documentation >>>>>>> tracker items, >>>>>>> the mailing header would indicate, who was posting it. >>>>>>> In addition it would allow others to look up the approved tracker >>>>>>> items. In the cases where a patch is missing, but the tracker item is >>>>>>> clearly formulated, then you, or everybody else would be "empowered" ;) >>>>>>> to change the explanation, the explanation, and to handle the change >>>>>>> without asking anyone. This way we might become able to address over >>>>>>> time the documentation tracker items, which would be especially >>>>>>> important for the users of ooRexx. >>>>>>> >>>>>>> ---rony >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mon, 27 Oct 2025 at 19:50, Rony G. Flatscher >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>> Hi Jon, >>>>>>>>> >>>>>>>>> On 27.10.2025 16:42, Sahananda wrote: >>>>>>>>>> I have read this, and I don't think that I can answer it quickly. >>>>>>>>>> It is more about project management and who makes the decision what >>>>>>>>>> goes into the language than anything technical. >>>>>>>>>> >>>>>>>>>> Where it is just a case of Josep Maria correcting mistakes in and >>>>>>>>>> improving the documentation (many thanks) I can make the judgement >>>>>>>>>> on readability, but I can't really say anything about technical >>>>>>>>>> correctness as most of these changes are in areas I'm unfamiliar >>>>>>>>>> with or I would need to spend time getting to know the context. >>>>>>>>>> >>>>>>>>>> As it is, I did not build the documentation with Josep Maria's >>>>>>>>>> patches, just judged the readability on the basis of the source xml. >>>>>>>>> Would it help, if someone would post a +1 with the tracker item then? >>>>>>>>> >>>>>>>>>> Were it native code, I would not be capable of 'judging' the merit >>>>>>>>>> or otherwise of a change to a C++ segment. >>>>>>>>>> >>>>>>>>>> When you requested someone to promote those 4 patches, I was happy >>>>>>>>>> to do it on the basis that I was just saving you some time with the >>>>>>>>>> mechanics of applying the patches which I assumed you had already >>>>>>>>>> judged the merits of. Later it became clear that P.O. could do it >>>>>>>>>> if I parsed the English. >>>>>>>>>> >>>>>>>>>> In principle, and time permitting, I am happy to take on the >>>>>>>>>> mechanics of applying patches if that frees resource from those like >>>>>>>>>> yourself capable of developing the code, but I do not want, without >>>>>>>>>> discussion, to create a precedent that leads to an unguarded way >>>>>>>>>> into the source code. >>>>>>>>> Thank you for this attitude, I really mean it! >>>>>>>>> >>>>>>>>> OTOH, there are quite a few tracker items where I think that you or >>>>>>>>> P.O. would be able to confidently handle them on your own. You are >>>>>>>>> both very knowledgeable ooRexx "users" for many, many years with a >>>>>>>>> lot of experience! >>>>>>>>> >>>>>>>>> It would be of great help, if the tracker items could be reduced as >>>>>>>>> much as possible, either by applying patches, assess the reasoning >>>>>>>>> and if you have an educated disagreement, then do not accept, >>>>>>>>> otherwise if you have an educated agreement, then please agree (and >>>>>>>>> maybe apply, fix), and if undecided, post a follow-up hinting at the >>>>>>>>> need to have an additional assessment. (This would be really very >>>>>>>>> helpful!) >>>>>>>>> >>>>>>>>>> If it was left to me, I have sufficient regard for Josep Maria, and >>>>>>>>>> knowing that he is active on the developers list and the ARB that I >>>>>>>>>> would invite him to become a committer. >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'm not asking that you (Rony) in particular solve this, and I do >>>>>>>>>> not have a particular proposal for how to solve it. I just wanted >>>>>>>>>> to flag up my concern. >>>>>>>>> Thank you very much, Jon! >>>>>>>>> >>>>>>>>>> I hope that is clearer >>>>>>>>> Very much so! >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> ---rony >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, 25 Oct 2025 at 21:52, Rony G Flatscher >>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>> Hi Jon and P.O., >>>>>>>>>>> >>>>>>>>>>> would it maybe possible that you come up with a brief draft, >>>>>>>>>>> suggestion? This way it wiuld probabky gelp the most and allow eg. >>>>>>>>>>> Myself to better unddrstand the problem and possible solutions. >>>>>>>>>>> >>>>>>>>>>> Cheers >>>>>>>>>>> >>>>>>>>>>> —-rony >>>>>>>>>>> Rony G. Flatscher (mobil/e) >>>>>>>>>>> >>>>>>>>>>>> Am 25.10.2025 um 20:38 schrieb P.O. Jonsson <[email protected] >>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>> >>>>>>>>>>>> Dear Rony, >>>>>>>>>>>> >>>>>>>>>>>> It is not just about the mechanics of applying a patch. What I >>>>>>>>>>>> think Jon is hinting at are guidelines for who and under what >>>>>>>>>>>> conditions parched are accepted. >>>>>>>>>>>> IMO it should really be up to the core developers if a patch >>>>>>>>>>>> should be allowed or not. If it is just about linguistic problems >>>>>>>>>>>> Jon may be in a position to help out (whereas I would prefer not >>>>>>>>>>>> to since I am not a native speaker). >>>>>>>>>>>> >>>>>>>>>>>> So some guidelines would be welcome indeed. >>>>>>>>>>>> >>>>>>>>>>>> Hälsningar/Regards/Grüsse, >>>>>>>>>>>> P.O. Jonsson >>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Am 25.10.2025 um 15:53 schrieb Rony G. Flatscher >>>>>>>>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>>>>>>>> >>>>>>>>>>>>> On 25.10.2025 15:24, Sahananda wrote: >>>>>>>>>>>>>> I have been thinking about this. If I apply a patch I am >>>>>>>>>>>>>> actually reviewing the providers work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We should really have some guidelines about this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just because I was given committer status a decade ago, doesn't >>>>>>>>>>>>>> mean that I have an overview of all the changes that are going >>>>>>>>>>>>>> on nor that I can necessarily be the arbiter of whether a patch >>>>>>>>>>>>>> should be committed or not nor whether it would need falling >>>>>>>>>>>>>> back. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I feel it would be helpful to me to have clearly stated >>>>>>>>>>>>>> procedures for accepting/rejecting/committing patches. >>>>>>>>>>>>> How about this for creating patches: >>>>>>>>>>>>> >>>>>>>>>>>>> a patch should be created in the "trunk" directory >>>>>>>>>>>>> How about this for applying patches: >>>>>>>>>>>>> >>>>>>>>>>>>> a patch must be applicable from the "trunk" directory >>>>>>>>>>>>> >>>>>>>>>>>>> before applying a patch the command "svn update" should issued to >>>>>>>>>>>>> get the latest version from Sourceforge >>>>>>>>>>>>> >>>>>>>>>>>>> then the patch should be applied locally with "svn patch >>>>>>>>>>>>> name-of-diff/patchfile" from the "trunk" directory >>>>>>>>>>>>> >>>>>>>>>>>>> if there are problems, because there are overlapping changes with >>>>>>>>>>>>> commits that occurred after the creation of the diff/patch file, >>>>>>>>>>>>> then this should be communicated in the respective tracker entry; >>>>>>>>>>>>> >>>>>>>>>>>>> the creator of the diff/patch can then do an "svn update" and see >>>>>>>>>>>>> where his changes overlap with the newer text and can resolve >>>>>>>>>>>>> them and then create an updated diff/patch file with "svn diff" >>>>>>>>>>>>> and submit it >>>>>>>>>>>>> >>>>>>>>>>>>> it may be the case that the problems are not complicated and can >>>>>>>>>>>>> be resolved on the side of the applyer of the diff/patch file by >>>>>>>>>>>>> inspecting the mark-up that "svn" applies >>>>>>>>>>>>> Here are two links that explain much better how svn conflicts can >>>>>>>>>>>>> be resolved: >>>>>>>>>>>>> >>>>>>>>>>>>> Tortoise (Windows): >>>>>>>>>>>>> <https://www.tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html> >>>>>>>>>>>>> >>>>>>>>>>>>> <https://www.tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html> >>>>>>>>>>>>> Command line (shown for Unix, but the command line is the same on >>>>>>>>>>>>> Windows): >>>>>>>>>>>>> <https://www.tutorialspoint.com/svn/svn_resolve_conflicts.htm> >>>>>>>>>>>>> <https://www.tutorialspoint.com/svn/svn_resolve_conflicts.htm> >>>>>>>>>>>>> There may be better explanations, tutorials on the net. >>>>>>>>>>>>> >>>>>>>>>>>>> Hope that helps >>>>>>>>>>>>> >>>>>>>>>>>>> ---rony >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, 25 Oct 2025 at 13:38, Rony G. Flatscher >>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>> One important hint about applying patches. It may be the case >>>>>>>>>>>>>>> that in the meantime someone else committed changes. In order >>>>>>>>>>>>>>> to make sure that everything is alright, one should always do a >>>>>>>>>>>>>>> "svn update" before a "svn commit". This way one can see before >>>>>>>>>>>>>>> the commit, whether there are areas which got concurrently >>>>>>>>>>>>>>> changed, in which case this needs to be resolved. However, >>>>>>>>>>>>>>> usually changes occur in different parts of the code, the >>>>>>>>>>>>>>> documentation and the tests which svn should be able to handle >>>>>>>>>>>>>>> (it is able to realize which version was used for the patch >>>>>>>>>>>>>>> and infer any changes in between and can usually apply patches >>>>>>>>>>>>>>> in full if they do not overlap). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ---rony >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 24.10.2025 17:40, Sahananda wrote: >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think I am now in a position to apply patches. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I reinstalled Tortoise, and now I see a child dialog of the >>>>>>>>>>>>>>>> diff dialog that I didn't notice before allowing me to choose >>>>>>>>>>>>>>>> which patch to action (it was a Hobsons Choice). The dialog >>>>>>>>>>>>>>>> was off my screen apart from a tiny sliver, but once I managed >>>>>>>>>>>>>>>> to grab it and drag it onto the screen I could choose the >>>>>>>>>>>>>>>> patch and then the diff was populated. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As P.O. had already applied the changes (thank you) and I had >>>>>>>>>>>>>>>> updated to the post change level while rebuilding my working >>>>>>>>>>>>>>>> copy to mirror Josep Maria's there was now no change left to >>>>>>>>>>>>>>>> apply, but I am confident that it would work in future. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As Rony says, the patch to be actioned should be placed in the >>>>>>>>>>>>>>>> folder above what is indicated in the Index: clause within the >>>>>>>>>>>>>>>> patch file. In this case, the 'docs' folder. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jon >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, 24 Oct 2025 at 16:14, Rony G. Flatscher >>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> First of all, thank you all *very* much for taking on the >>>>>>>>>>>>>>>>> patches and also all of your work in the documentation/patch >>>>>>>>>>>>>>>>> area! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sorry to read that you had so many problems with it, maybe a >>>>>>>>>>>>>>>>> few words, hints: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The path given at the beginning of the diff/patch files tells >>>>>>>>>>>>>>>>> one in which directory the creator of the diff/patch was >>>>>>>>>>>>>>>>> located; so if it starts with "trunk/rexxref/en-US/....xml", >>>>>>>>>>>>>>>>> it must have been the "docs" directory, so Josep Maria had >>>>>>>>>>>>>>>>> that from the Sourceforge project checked out, but P.O. and >>>>>>>>>>>>>>>>> Jon did probably check out the doc's "trunk" directory (and >>>>>>>>>>>>>>>>> all its subdirectories), but not the directory "docs" in >>>>>>>>>>>>>>>>> which "trunk" and the "releases" are located. Therefore >>>>>>>>>>>>>>>>> applying the patch did not work. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Maybe to ease handling, please create the diff/patches from >>>>>>>>>>>>>>>>> within the "trunk" directory (underneath a possibly existing >>>>>>>>>>>>>>>>> "docs" directory), then the diff/patch should start with >>>>>>>>>>>>>>>>> "rexxref/en-US/....xml" instead and one can apply them from >>>>>>>>>>>>>>>>> "trunk" then. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ad forward slashes: these should work on the Windows version >>>>>>>>>>>>>>>>> of svn as well. >>>>>>>>>>>>>>>>> Please keep up your great work! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ---rony >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 24.10.2025 12:41, Josep Maria Blasco wrote: >>>>>>>>>>>>>>>>>> The revision number shouldn't matter, as far as I know. >>>>>>>>>>>>>>>>>> It was the current one when I uploaded the patches. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regarding the paths, the instruction set I'm following reads >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Once you are ready with the intended changes, >>>>>>>>>>>>>>>>>> go up to the root of the documentation and issue "svn diff > >>>>>>>>>>>>>>>>>> myPatchForChapter3.1.2.diff" >>>>>>>>>>>>>>>>>> which will write all the changes to that text file. Submit >>>>>>>>>>>>>>>>>> that diff-file (patch-file) as a patch[...] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Maybe the boldfaced part explains the difference? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Josep Maria >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Missatge de Sahananda <[email protected] >>>>>>>>>>>>>>>>>> <mailto:[email protected]>> del dia dv., 24 d’oct. 2025 a >>>>>>>>>>>>>>>>>> les 10:47: >>>>>>>>>>>>>>>>>>> I would also be interested in an answer to this. I tried >>>>>>>>>>>>>>>>>>> creating a patch locally and noted these differences from >>>>>>>>>>>>>>>>>>> Josep Maria's patch. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The file references did not have paths. >>>>>>>>>>>>>>>>>>> My Working copy was at revision 13031 whilst Josep Maria's >>>>>>>>>>>>>>>>>>> was at 13026 >>>>>>>>>>>>>>>>>>> I also note that Josep Maria's patch which contained >>>>>>>>>>>>>>>>>>> directory information used '/' as the path separator. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Jon >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> My Header >>>>>>>>>>>>>>>>>>>> Index: intro.xml >>>>>>>>>>>>>>>>>>>> =================================================================== >>>>>>>>>>>>>>>>>>>> --- intro.xml (revision 13031) >>>>>>>>>>>>>>>>>>>> +++ intro.xml (working copy) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Josep Maria's Header >>>>>>>>>>>>>>>>>>>> Index: trunk/rexxref/en-US/intro.xml >>>>>>>>>>>>>>>>>>>> =================================================================== >>>>>>>>>>>>>>>>>>>> --- trunk/rexxref/en-US/intro.xml (revision 13026) >>>>>>>>>>>>>>>>>>>> +++ trunk/rexxref/en-US/intro.xml (working copy) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, 24 Oct 2025 at 08:15, ooRexx <[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I wanted to apply the patches proposed by Josep Maria but >>>>>>>>>>>>>>>>>>>> failed miserably to do so. I have now applied the changes >>>>>>>>>>>>>>>>>>>> indicated in doc_bug_326.diff manually and that worked so >>>>>>>>>>>>>>>>>>>> there is nothing wrong with my SVN. I nevertheless would >>>>>>>>>>>>>>>>>>>> like to know why the patch did not work. Here is what I >>>>>>>>>>>>>>>>>>>> did: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> % cd >>>>>>>>>>>>>>>>>>>> /Users/jenkins/ooRexxSVN-Code-0/docs/trunk/rexxref/en-US >>>>>>>>>>>>>>>>>>>> % svn update >>>>>>>>>>>>>>>>>>>> Aktualisiere ».«: >>>>>>>>>>>>>>>>>>>> Revision 13031. >>>>>>>>>>>>>>>>>>>> % svn patch /Users/jenkins/Downloads/doc_bug_326.diff >>>>>>>>>>>>>>>>>>>> C trunk/rexxref/en-US/instrc.xml >>>>>>>>>>>>>>>>>>>> > Abschnitt @@ -2081,9 +2081,8 @@ zurückgewiesen >>>>>>>>>>>>>>>>>>>> Konfliktübersicht: >>>>>>>>>>>>>>>>>>>> Textkonflikte: 1 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What am I doing wrong? >>>>>>>>>>>>>>>>>>>> Is the patch not in the correct form? >>>>>>>>>>>>>>>>>>>> Or do I have to perform the patches in a specific order? >>>>>>>>>>>>>>>>>>>> I am on r13031 and the patch was made at r13026, does that >>>>>>>>>>>>>>>>>>>> make a difference? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Here the rejection grounds >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --- trunk/rexxref/en-US/instrc.xml >>>>>>>>>>>>>>>>>>>> +++ trunk/rexxref/en-US/instrc.xml >>>>>>>>>>>>>>>>>>>> @@ -2081,9 +2081,8 @@ >>>>>>>>>>>>>>>>>>>> in this case must be either >>>>>>>>>>>>>>>>>>>> <computeroutput>SCIENTIFIC</computeroutput> or >>>>>>>>>>>>>>>>>>>> <computeroutput>ENGINEERING</computeroutput>. You can >>>>>>>>>>>>>>>>>>>> omit the subkeyword >>>>>>>>>>>>>>>>>>>> VALUE if <emphasis role="italic">expression2</emphasis> >>>>>>>>>>>>>>>>>>>> does not begin with a >>>>>>>>>>>>>>>>>>>> -symbol or a literal string, >>>>>>>>>>>>>>>>>>>> -that is, if it starts with a special character, such as >>>>>>>>>>>>>>>>>>>> an operator character >>>>>>>>>>>>>>>>>>>> -or parenthesis.</para> >>>>>>>>>>>>>>>>>>>> +symbol, that is, if it starts with a string or a special >>>>>>>>>>>>>>>>>>>> character, >>>>>>>>>>>>>>>>>>>> +such as an operator character or parenthesis.</para> >>>>>>>>>>>>>>>>>>>> <para>You can retrieve the current NUMERIC FORM setting >>>>>>>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>>>>>>> <xref linkend="bifForm" xrefstyle="select:title"/> >>>>>>>>>>>>>>>>>>>> built-in function. >>>>>>>>>>>>>>>>>>>> </para> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hälsningar/Regards/Grüsse, >>>>>>>>>>>>>>>>>>>> ooRexx >>>>>>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>> _______________________________________________ >>>>> Oorexx-devel mailing list >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> [email protected] >>>> <mailto:[email protected]> >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> -- >>> -- >>> __________________________________________________________________________________ >>> >>> Prof. Dr. Rony G. Flatscher, iR >>> Department Wirtschaftsinformatik und Operations Management >>> WU Wien >>> Welthandelsplatz 1 >>> A-1020 Wien/Vienna, Austria/Europe >>> >>> http://www.wu.ac.at <http://www.wu.ac.at/> >>> __________________________________________________________________________________ >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
