On Fri, Sep 30, 2011 at 17:20, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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).
>
In that case -h (--human-readable) option for svn mergeinfo command
makes sense for me.
--
Ivan Zhakov
Received on 2011-09-30 15:28:11 CEST