On Fri, Sep 30, 2011 at 2:42 PM, Stefan Sperling <s...@elego.de> wrote: > On Fri, Sep 30, 2011 at 12:24:04PM +0100, Julian Foad wrote: >> I've been thinking about a bunch of issues related to merging and how to >> help users to avoid some of the common pitfalls. One subset of my >> thoughts is on how we can present information about merges in a more >> user-friendly high-level way so that each time a user runs "svn merge" >> or "svn mergeinfo" they get feedback that relates to their high-level >> idea of what should be happening, and thus helps them to see at a glance >> whether they issued the right command for what they wanted to achieve. > > I like this. > > The current output of 'svn mergeinfo' (one revision per line) > is suited well for consumption by scripts but not by humans.
[...snip...] > Some thoughts regarding backwards compatibility: > > In principle, we should keep the current output by default (for backwards > compat), and add a new switch that enables human-readable output. > However, I think that in this case breaking compatibility in favour > of user-friendliness is highly justified. > > So I think the default output should be replaced completely with something > better, in addition to an --xml switch that produces XML output for > consumption by scripts. We could have the --show-revs switch enable the > old-style output (one revision per line) to provide those who have already > written scripts which parse this output with a migration path. Yes, please keep the old output (one rev per line) available somehow. I have developed quite a lot of scripts in our company that use 'svn mergeinfo' to help our developers pick the right revision(s) for cherry-picking to release branches. We also have a script that uses mergeinfo to build automatic release notes based on (parsing of) log messages. It performs 'svn mergeinfo $URL/to-be-released-branch $URL/production-branch' to see which revisions are unique to the new release, which weren't part of the previous production branch (this filters out revisions that were cherry-picked to production-branch and released as patches thereof). If the old style is no longer the default, I can live with that (though I'd prefer not having to change my scripts for this, but at least it's doable). -- Johan
