On Sun, May 18, 2025 at 9:48 PM Branko Čibej <br...@apache.org> wrote:
> On 23. 11. 24 11:26, Timofei Zhakov wrote: > > Hi! > > I am using patches frequently, however, 'svn diff' and 'svn patch' > commands currently have several limitations: > > 1. They do not track tree changes (like copies and moves) > 2. Binary file modifications are not tracked in plain-text patches > 3. Unidiff patches use 2-way merge instead of 3-way merge, so in case > of conflict, the patch/hunk/file/directory will be rejected. > > The ideas I would suggest to solve these problems will be explained below: > > 1. Add `svn diff --xpatch` for creating binary patches. > 2. Add `svn merge --xpatch FILENAME` for applying them onto a working copy. > 3. Optionally, we can also implement several commands to browse xpatch > files using the command-line interface. For example, previewing them > as unidiff or showing the diff-summary. > > In my opinion, the best way to save the changes is to write them to an > XML file/stream (btw, this is why I would name this feature as > "[x]patch"). I will explain the format in detail soon. > > > So, I see that the implementation has begun without that xpatch format > actually being defined. > Not exactly. I wanted to make a branch so we can experiment with the command line interface in action, but without it actually doing anything. Of course it's important to discuss the format before implementing, so we all agree, and this won't cause conflicts in the future. Basically, I have my vision of what the format could be, so I could start the discussion about it. I even documented it, and we have a good base to initiate it. However, I don't want to start developing the feature before 1.15 is out (I think I already explained it in one of my previous emails in the thread about the release). But this is a reason why I shouldn't have made the branch :)) > Before all this goes too far, there should be a formal-ish schema for this > format. And before anyone starts reinventing the wheel: let me just point > out that in the very early days, before Subversion had a server/repository > implementation, we _did_ have an edit driver. That driver wrote and read > (what else?) XML files. That would most probably be the place to start: > there's existing code deep in the history of our repository. > Oh, it seems interesting. I'll try to find it. Thanks for pointing this out. > [...] Not yet ready for a detailed response. Sorry... PS: great work in the patch parser! -- Timofei Zhakov
