On 15.02.2015 14:24, Branko Čibej wrote: > On 15.02.2015 01:03, Bert Huijben wrote: >>> -----Original Message----- >>> From: Branko Čibej [mailto:br...@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
