On 16.02.2015 10:27, Bert Huijben wrote: > >> -----Original Message----- >> From: Branko Čibej [mailto:br...@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: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. > +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
