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]>:

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




Am 25.10.2025 um 15:53 schrieb Rony G. Flatscher <[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:

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]> 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]> 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]> 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]> 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


_______________________________________________
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
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to