I would like to see the internal file merge to be of equal citizenship with
external merge tools. Like Daniel said elsewhere, extracting it as a separate
executable is one way to achieve that.
"file merge" is a great name, except it's not the name we already use for
specifying the file merge tool and its options. We call it the "--diff3-cmd"
(in the config file it's "diff3-cmd", and there's also a "merge-tool-cmd" with
slightly different semantics that's used on request from the interactive
resolver or --accept=launch option), and for its options there is
"--extensions/-x" ("diff-extensions"). For plain diff we have "--diff-cmd" and
"--extensions/-x" ("diff-extensions").
So for a start it might make sense to use the existing "extensions" option
which is intended for passing options to the file merge tool, until we re-vamp
the whole diff/merge invocation mechanisms.
- Julian
Stefan Sperling wrote:
> the patch below adds a --file-merge option, in an attempt to solve
> issue #4487 "add a scriptable non-interactive option for additive
> merges"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4487
>
> There's been a discussion on IRC about this today:
> http://colabti.org/irclogger/irclogger_log/svn-dev?date=2014-04-07#l116
> Before jumping there, please read my wrap-up below.
>
> A new --file-merge option is the simplest way of solving this
> problem I could come up with. It maps the options provided by
> the internal merge tool to a command line flag:
>
> --file-merge ARG : Set a pre-defined choice ARG for the built-in
> file
> merge tool, which otherwise prompts
> interactively.
> --file-merge applies to text conflicts only and
> overrides the --accept option for file merges.
> ARG is any of 1, 2, 12, 21, e1, e2, or eb:
> (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
>
> But it's just an ad-hoc idea, so I would like to get some feedback.
> I'm curious if anyone else has other ideas.
>
> Among other ideas discussed on IRC where:
>
> - Currently the file merge tool is only reachable from the interactive
> conflict resolution handler. We could split the internal merge tool
> off into a seperate program shipped with Subversion (let's call this
> svn-file-merge for this discussion) so it could be run standalone:
>
> svn-file-merge [--default-answer=(1|2|12|21)] FILE1 FILE2 FILE3 OUTPUT_FILE
>
> This should allow scripts to configure a merge tool as needed, e.g.
>
> svn update --config-option config:helpers:merge-tool-cmd \
> 'svn-file-merge --default-answer=21'
>
> Note that this approach might also fix issue #4426 since the
> distinction between internal and external merge tools becomes
> meaningless (this might be of interest to Ben Reser in case he's
> reading).
>
> - If we're considering exposing the file-merge tool functionality via a
> seperate CLI tool, we might also take into account the possibility of
> exposing it directly via an 'svn' subcommand.
>
> E.g. we could add a new mode to 'svn merge' which unlike 'svn
> resolve' skips the standard conflict prompt and runs the built-in
> merge tool interactively, or with an --file-merge option similar
> to the one in the patch below.
> It would be invoked like this, for instance:
>
> svn merge [--file-merge=(1|2|12|21)] FILE1 FILE2 FILE3 OUTPUT_FILE
>
> All input files would need to be unversioned to trigger "merge tool mode".
> 'svn merge' could then be invoked as an "external" merge tool and would
> also be the pre-configured default merge tool.
>
> svn merge --config-option config:helpers:merge-tool-cmd \
> 'svn merge --file-merge=21'
>
> This looks a bit circular, but users who don't suffer from issue
> #4487 wouldn't even need to know about this quirk. And perhaps this
> is preferable to adding yet another separate utility or subcommand.
>
> Would anyone prefer the above possibilities to the patch below?
> Any other ideas?
