On 16.02.2015 10:27, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane_at_wandisco.com]
>> Sent: maandag 16 februari 2015 03:14
>> To: 'Subversion Development'
>> Subject: Re: Time to branch 1.9
>>
>> 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.
> +1 Thanks.
>
> For simple commits it might be even easier to expose something 'svnmucc' like in the future, based on mtcc...
> building a working copy-like structure in ram based on simple streams and properties and then a simple commit.
Yes, I'd considered that; however, exposing the RA API without an editor
is sort of limited. As soon as we decide to make svn_client_mtcc public,
exposing it in JavaHL should be quite simple.
-- Brane
Received on 2015-02-16 11:36:50 CET