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.
-- Brane
Received on 2015-02-15 14:26:18 CET