On 18. 5. 25 22:09, Timofei Zhakov wrote:
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.
I suggest you start at r836846. Yes, way before 1M revisions, this was
still CVS. :)
> [...]
Not yet ready for a detailed response. Sorry...
Sure, there's no rush.
-- Brane
