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.
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.
However, I'm going to throw some spanners in the wheels.
First of all: the big, huge, humongous, incomparable benefit of unidiffs
(with or without properties) or git patches is that they're
human-readable. XML has the unenviable distinction of being *both*
almost unreadable for humans *and* very finicky to parse for machines.
So, for future sanity of our users and ourselves, I'd very much prefer
to stay away from XML, especially given that we don't actually have a
schema-validating XML parser.[1] Although we use XML in command output,
those documents are much simpler than an edit drive would produce.
That said, XML is at least standardised. If we can get some schema
validation, it might be a viable (and not-completely-new-in-subversion)
format.
We already use extended unidiffs in two ways:
* to represent property changes in patch files; and,
* to represent /some/ tree mutations and binary diffs, with --git
Neither of that is enough, as you note, since we don't have a
representation for tree mutations; or, only incidentally and implicitly
in the --git format, and not for all of them
There's a reason why we decided to extend unidiff the way we did: the
result is still an easily recognisable and human-readable format. So,
before going into something completely new, I'd take a closer look at
adding further extensions to unidiff so that a) the enhanced format can
represent an edit drive and b) is still compatible with standard Unix
'patch', albeit with some limitations on the results and c) can be used
by our patch implementation to achieve the goals of the xpatch branch.
On the flip side, our current patch parser implementation is already a
bit of a mess and could probably do with more eyes looking at it. I've
been doing some of that for the last couple of days and, well, I still
don't quite understand how it works. Adding more features to it would be
less than trivial.
-- Brane
[1] We do have Relax-NG schemas for some of the --xml comand outputs,
though I'm not sure how up-to-date they are; but I don't think we even
use them for validation in the test suite.
