On Fri, Sep 30, 2011 at 2:42 PM, Stefan Sperling <stsp_at_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
Received on 2011-09-30 15:21:10 CEST