Den lör 23 nov. 2024 kl 11:26 skrev Timofei Zhakov <t...@chemodax.net>:
> 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. > > Recently, I was doing research about how the merge works and about the > ways to reuse its implementation for creating some kind of binary > patches. > > It is currently implemented using a svn_diff_tree_processor, which > applies the differences, resolves conflicts. I.e. it edits the working > copy and resolves the conflict cases. > > However, there are some technical limitations in the current merge > implementation, which prohibit it to be used outside of the merge > command, but the merge implementation can be split onto two files; the > merge itself and the "apply" tree-processor. > > I have a prototype of factoring-out the "apply" tree-processor from > merge. In general it seems to be working with most test cases passing. > Additionally, as you might already have seen, I committed some > improvements a while ago, which are related to this. > > I am planning to do the following to implement binary patches: > > 1. Factor-out "apply" tree-processor from merge.c to another file of > private client API. > 2. Do some preparations for xpatching in the 'trunk'. > 3. Create a branch for the xpatch feature. > 4. Implement writer and parser for xpatch files in the branch. > 5. Add`svn diff -–xpatch` and `svn merge -–xpatch` commands by > connecting diff driver, xpatch file routines, and "apply" > tree-processor together in the same branch. > > I have a working prototype of xpatch file writer and parser, but it > seems to be far from ready. > > -- > Timofei Zhakov > Hi, A little late to the party but I'll reply to the original e-mail: I understand this as a suggestion to implement a new diff/patch format that: - Handles binary files. - Handles tree changes (moves). - Better applies to a tree with modifications since it is applied as a "merge" rather than a patch. It this a correct understanding of the goal? Do we have consensus on dev@ that these are something we would like to have? I'm explicitly not seeking consensus for a particular implementation, this will be discussed later. For the record, I'm +1 for the feature as described above. Kind regards, Daniel
