On Fri, Sep 30, 2011 at 17:20, Johan Corveleyn <jcor...@gmail.com> wrote: > 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). > In that case -h (--human-readable) option for svn mergeinfo command makes sense for me.
-- Ivan Zhakov
