> -----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.
Bert
