On Tue, Nov 26, 2024 at 5:06 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote:
> 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 > There are a few additional limitations to unidiff patches, such as: they cannot represent an empty file (files whose contents are removed by a unidiff patch are scheduled for deletion) and they cannot represent directory creation or deletion. If I understand the idea correctly, the new patch format will be able to represent all types of working copy changes. Also with the way unidiff patches are applied, we instruct the user (in 'svn help patch') to find the revision at which the patch was made, update to that revision, apply the patch, and then update to HEAD to get merging and conflict resolution. Since the new patch format will be able to represent changes more fully, they will be able to be applied to a working copy tree that has had potentially a substantial amount of other changes since it would benefit from 3-way merge and conflict resolution. I'm +1 for having something like this. I have written some specific thoughts about it which I plan to share soon... Cheers, Nathan
