I posted the following question to the subversion users mailing list, where Stefan Sperling responded suggesting that I submit it as an enhancement request (full discussion here: http://svn.haxx.se/users/archive-2014-03/0189.shtml)... ____________ If you attempt to "svn merge" a text file from the command-line where the same line has been modified in both file versions, you will see a report of the conflict, followed by this menu: Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options If you then choose "m" for merge, you will see this menu: Select: (1) use their version, (2) use your version, (12) their version first, then yours, (21) your version first, then theirs, (e1) edit their version and use the result, (e2) edit your version and use the result, (eb) edit both versions and use the result, (p) postpone this conflicting section leaving conflict markers, (a) abort file merge and return to main menu Choosing either (12) or (21) here will perform an additive merge where both changes are included in the resulting file. We need this behavior for one of our standard use cases, and therefore we would like to script it, but I don't see a way to perform this type of additive merge in a non-interactive way. None of the standard --accept options that can be used with "svn merge" would seem to trigger this behavior. Am I missing something, or are these additive merges only possible in interactive mode? _______________ Stefan's reply: _______________ currently it's only available in interactive mode, I'm afraid. The --accept option internally corresponds to some of the options shown by the first-level conflict prompt: Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options The ('m' merge) option invokes the built-in file merge tool which was added by me in 1.8.0. This tool is not integrated with --accept. I hadn't considered the possibility that users might want to drive this tool from scripts and I agree this would be useful. I'm not sure if adding yet more options to --accept would be a good way of making the internal merge tool scriptable, though. Perhaps a new option could be introduced for this purpose (e.g. --file-merge)? But I'm not sure how this would interact with --accept mine-conflict, for instance. Hmm... The problem I have with --accept is that it is applied to any kind of conflict (text/prop/tree), except when its value is not applicable to the conflict in question :) I.e. the --accept UI is already a bit flawed and not flexible enough to be useful in many common cases. Defining even more values for --accept might not be a good idea, especially if they are geared towards a single type of conflict (text conflicts in your case). But we should be able to come up with a suitable and scriptable UI. I tend to be careful with UI design and hope that there will be some discussion about possibilities we have here. Any other ideas? If you'd like to, please file an ENHANCEMENT request for this idea in our issue tracker. See http://subversion.apache.org/reporting-issues.html And please feel welcome to discuss related UI ideas on the dev@ list.
Original issue reported by j_p