Karl Fogel wrote:
> You mentioned two that were of special concern:
>
>> * r31059, 31060, 31061, 31075, 31151
>> Fix issue #3157, Merging a change from a path's natural history
>> creates self-referential mergeinfo
>>
>> I would like to see this in 1.5.0 because once the "bad" mergeinfo is
>> created you cannot fix it. Note, that the mergeinfo is only bad for
>> log -g, not merge itself. But we have run into this problem on our
>> own repository, as well as via a user testing the RC. So we know it
>> is real.
>
> That sounds pretty serious. But is it absolutely necessary that it go
> in? Can't mergeinfo be edited? How often is this likely to happen
> anyway? If it waited for 1.5.1, would that be a disaster? We can't
> keep folding in serious bugfixes and then pretending they aren't exactly
> what our soak time is intended to soak.
Mergeinfo is versioned, and therefore can't be (easily) retroactively edited.
>> * r31243, r31246, r31249, r31250, r31251, r31271
>> Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
>> "extra revprops"; the svn_client APIs should
>> Notes:
>> If we *don't* backport this in 1.5.0, we need to undo the changes
>> or otherwise rework them to use newly-revved svn_client APIs.
>> This is not quite finished -- need feedback from Ruby, Perl, and
>> JavaHL bindings maintainers.
>>
>> Since it is fixing the API it has to go into 1.5.0 or pretty much just
>> be undone. I want to be against this change as not being worth the
>> risk, but I suspect the API ickiness in this case is probably worth
>> fixing.
>
> Sure, this was just an API untwisting, not a "real" code change. As
> long as we have enough eyeballs on it, I think there's little real risk
> in letting it in with just a one- or two-week soak.
Agreed.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-05-19 22:58:53 CEST