Yay! Consensus amongst the most active parties!
I will drive these changes ASAP (realistically, tomorrow).
Julian Foad wrote:
> C. Michael Pilato wrote:
>> Paul Burba wrote:
>>
>>> Here is my (probably futile) attempt to define what the bare minimum is:
>>>
>>> A) Revisions are displayed one per line (no ranges)
>>
>> +1
>>
>>> B) Inoperative revisions are filtered out, but for merged and eligible
>>> revisions*
>>
>> +1
>>
>>> C) Support only one TARGET path/URL
>>
>> +1
>>
>>> D) Require --from-source.
>>
>> Requiring an option (like --from-source) is weird. They're supposed
>> to be OPTIONal. :-) Should we drop --from-source, and make the usage
>> syntax similar to 'svn merge' itself?
>>
>> $ svn mergeinfo SOURCE [TARGET[@PEG-REV]]
>
> +1. Having the syntax be more like "svn merge" is (a) very logical
> because that's exactly the kind of inputs we're specifying, and (b) less
> typing. (For some reason I can't articulate, a non-optional option
> didn't actually bother me much, but this is better all round.)
>
>
>>> E) Show merged revisions by default. Add a new option --show-revs
>>> ['merged' | 'eligible'] allowing eligible to be shown instead.
>>
>> +1
>>
>>> F) Make recursive by default, i.e. any subtrees of the TARGET with
>>> their own explicit mergeinfo are listed separately. This implies at
>>> least one level of indentation.
>>
>> As I expressed in IRC, this adds some trickiness. We'll have to
>> bifurcate the logic so that URL TARGETs make use of the
>> include_descendants=TRUE flag to svn_ra_get_mergeinfo(), but working
>> copy TARGETs will have to be crawled in full with either per-item
>> invocations of get_mergeinfo() (which is awfully expensive, and grows
>> in cost the deeper in the tree you get) or custom inheritance-tracking
>> logic. (This special-casing of WC TARGETs due to needing honest
>> answers in light of mixed revs, switched children, etc.)
>>
>> So, defaulting to --depth=infinity today complicates the work of
>> getting us ready for 1.5.
>
> +1 on being non-recursive (depth=empty) and not supporting the "--depth"
> option yet. We can add it in The Future.
>
>> On the flip side, adding --depth support in 1.6 means adding a level
>> of indentation (unless we go ahead and build that into 1.5), but also
>> likely means dealing with depths of dubious value (is 'svn mergeinfo
>> --depth files' likely to be terribly useful?). Maybe that's not a big
>> deal ... the same could probably be said about the depth support in
>> many of our subcommands.
>
> I don't think it matters much whether we provide any indentation now.
> The chance of it exactly matching our future 1.6 outputs is ... well,
> not 100%, at least, so it's hardly worth bothering.
>
>> (We're close ... can you taste it?)
>
> Yes, the taste of sweet simplicity. All is settled and should be ready
> very soon.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-04-01 22:24:58 CEST