Re: Is there a non-interactive way to do a "your version first, then theirs" merge?

Thanks a lot Stefan. At your suggestion I added this as an enhancement request: http://subversion.tigris.org/issues/show_bug.cgi?id=4487 I don't have any opinion on whether a new --accept option or an entirely new flag is best. I defer to your experience and judgment there. Thanks very much to you and your svn colleagues for any consideration of including this option in a future release. In the meantime, can you think of any workaround that we could cobble together using the merge-tool-cmd config option and/or the --diff-cmd flag (which I realize is only available on diff, not merge), in conjunction with some specially scripted or flagged invocation of GNU diff3? Let me know if you have any ideas. Much thanks, -JP On Monday, March 31, 2014 9:33 AM, Stefan Sperling <stsp@elego.de> wrote: On Mon, Mar 31, 2014 at 05:36:10AM -0700, JP wrote: > I'm currently using svn 1.8.5 on the client and 1.8.3 on the server. > > > 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? > > Thanks in advance for any replies. > > -JP Hi JP, 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. Thanks! Note also that we cannot change or add options in patch releases. So if this feature was implemented it would appear in 1.9.0 at the earliest.
Received on 2014-03-31 19:58:49 CEST