Timofei Zhakov wrote on Sat, 23 Nov 2024 10:26 +00:00: > Hi! > Nice to meet you :)
> 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. What would this do that «svn diff --git» doesn't already do? > 2. Add `svn merge --xpatch FILENAME` for applying them onto a working copy. Don't leak implementation details into the API/CLI. In CLI terms, applying a patch isn't a kind of merge, notwithstanding the libsvn_client implementation details. In general, don't add --options that make a command do something entirely different; rather, have each subcommand "do one thing and do it well". The standard example for that is «svn switch --relocate», now known as «svn relocate». > 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"). Again, leaky abstraction. Please name the thing based on its API rather than based on its implementation. There's a reason Air Force One's callsign isn't "Biden One", you know :-) Moreover, we have a bunch of cmdline options named --x-*, which are "experimental". (Coincidentally, most of these are related to shelving.) --xpatch could be taken for experimental as well, if so named. Cheers, Daniel
