On 15.02.2015 14:24, Branko Čibej wrote:
> On 15.02.2015 01:03, Bert Huijben wrote:
>>> -----Original Message-----
>>> From: Branko Čibej [mailto:brane_at_wandisco.com]
>>> Sent: donderdag 12 februari 2015 11:13
>>> To: Subversion Development
>>> Subject: Re: Time to branch 1.9
>>>
>>> On 16.01.2015 11:06, Branko Čibej wrote:
>>>> A couple months down the line, and I'd like to make another call for
>>>> creating the 1.9 release branch. AFAICS the x509 branch still needs
>>>> merging if we want it in 1.9 (which I think we do, since IIUC trunk
>>>> currently does not handle all certs correctly).
>>>>
>>>> Anything else?
>>>>
>>>> I'd like to propose that we cut the branch and roll an RC (or a beta) in
>>>> a couple weeks.
>>> Looks like we're on track for branching around the beginning of next week.
>>>
>>> * the x509 branch is on trunk;
>>> * the heisenbug (actually, several heisenbugs) in ra-test seem to have
>>> been fixed;
>>> * Stefan^1 's pin-externals branch has been lazy-consensus'd for merge
>>> to trunk (some changes still pending, but those don't have to happen
>>> on the branch);
>>> * The problem with Python bindings and Swig 3.0.x is, for now, assumed
>>> to be a bug in Swig itself; I propose we disable support for Swig-3
>>> for now (Swig-2 still works fine);
>>> * Ivan and I agreed not to propose to merge the reuse-ra-session
>>> branch in time for 1.9, we can merge it after the soak period an let
>>> it marinate a bit on trunk for 1.10;
>>> * Bert appears to be mostly finished with his (fantastic!) fixes for
>>> working copy move handling and conflict resolution;
>>> * buildbots are green.
>>>
>>> If there are no further objections, and the pin-externals branch gets
>>> merged soon-ish, I intend to create the 1.9 release branch on Sunday
>>> night or Monday early morning (UTC). Ben has kindly been volunteered to
>>> RM the first 1.9 release candidate
>> +1
>>
>> One more thing:
>> * I think some bits of EditorV2 are still exposed via JavaHL, while we decided not to expose this api at the C layer.
>>
>> We should probably mark this experimental, remove it, separate it, or...
> ... leave it in. JavaHL does not expose an experimental C API. It
> exposes an editor interface that happens to currently depend on the Ev2
> shims, but could in future depend on Ev3, or some other editor
> interface, or shims local to the JavaHL implementation.
>
> The point is that the JavaHL editor, as currently used for commit and
> status over RA (without the client layer), is much easier to use than
> the delta editor.
>
> Rewriting the implementation to use the delta editor directly would be
> nothing more nor less than copying the Ev2 shim implementation into
> libsvnjavahl, which doesn't make sense. The Java API itself is similar
> enough to the current Ev3 design that it shouldn't be too hard to change
> the implementation once Ev3 is done.
>
> I'm strongly -1 to exposing the delta editor API in JavaHL; it's just
> too convoluted.
I documented that the interface is experimental; should be enough for
now, IMO.
-- Brane
Received on 2015-02-16 03:14:10 CET