You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2011/04/07 17:19:48 UTC
1.7 Roadmap Items Evaluation
I'm looking at a number of things right now, trying to get a handle on
exactly where 1.7 is in its slow trek towards completion. Obviously, we
have the issue tracker and its issues as one guidepost, but I'm also looking
at some of the other meta-issues we've chosen to track on our roadmap page
-- the stuff that's a bit more publicly visible -- which are not yet marked
as "Completed":
"WC-NG": Well... duh.
"Externals": This one concerns me. The referenced issue (#3818) implies
that we plan to completely rework our storage and handling of externals in
the 1.7 timeframe. Further, there are references to regressions against
1.6.x, which would seem at first glance to prevent us from deferring until a
future date. Can someone speak with confidence and knowledge about all of this?
"Remove obliterate code": I think the obliterate code is all tucked away in
private functions and such at this point. Is that as far as we plan to take
this in 1.7? If not, the purge of this stuff would be some pretty
low-hanging fruit for a would-be contributor.
"Review of performance branch": I get the sense from the list traffic that
we've kinda pulled what we want from this branch into trunk for now. Can
someone confirm?
"libsvn_ra_serf stabilization": Ivan and others have made progress in this
space, and AFAIK the Serf project has made the "new public release of serf
which contains the fix for the massive SSL memory leak" that we call for.
What's left?
"Test Review" / "API Review": Good stuff. This needs to happen. *waves hands*
"Remove temp APIs": I would put this at "nice to have". These APIs are
private, so what's the penalty if they wind up in the release?
"Issue triage": This has been happening along the way, at different rates
and by several folks. I *think* our 1.7.0 milestone is pretty tight at this
point, in terms of not carrying non-blockers. There may be still more that
could be deferred, but it's pretty tight.
"API performance analysis": We're doing some amount of this right now,
though more at the operational level than at the API level. This is where I
see value in hearing from our third-party API consumers/friends. We sorta
put Stefan King on hold for a while while we were dinking around at higher
levels in WC-NG. Would others agree that at this point, we're a bit more
free to start soliciting (and responding to) performance evaluations from
the likes of TortoiseSVN, AnkhSVN, subclipse, etc.?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7 Roadmap Items Evaluation
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/09/2011 07:29 AM, Stefan Fuhrmann wrote:
> On 07.04.2011 17:19, C. Michael Pilato wrote:
>> "Review of performance branch": I get the sense from the list traffic that
>> we've kinda pulled what we want from this branch into trunk for now. Can
>> someone confirm?
>
> Someone can and I do ;) The remaining 20% of the patches
> on the performance branch are not 1.7 material.
Thanks. I've marked this item "Completed" on the Roadmap page.
>> "API performance analysis": We're doing some amount of this right now,
>> though more at the operational level than at the API level. This is where I
>> see value in hearing from our third-party API consumers/friends. We sorta
>> put Stefan King on hold for a while while we were dinking around at higher
>> levels in WC-NG. Would others agree that at this point, we're a bit more
>> free to start soliciting (and responding to) performance evaluations from
>> the likes of TortoiseSVN, AnkhSVN, subclipse, etc.?
>
> As a TSVN developer and user: +1 on that.
Great. Then, as a TSVN developer, we look forward to hearing your feedback
and suggestions on API performance. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7 Roadmap Items Evaluation
Posted by Stefan Fuhrmann <eq...@web.de>.
On 07.04.2011 17:19, C. Michael Pilato wrote:
> "Review of performance branch": I get the sense from the list traffic that
> we've kinda pulled what we want from this branch into trunk for now. Can
> someone confirm?
Someone can and I do ;) The remaining 20% of the patches
on the performance branch are not 1.7 material.
> "API performance analysis": We're doing some amount of this right now,
> though more at the operational level than at the API level. This is where I
> see value in hearing from our third-party API consumers/friends. We sorta
> put Stefan King on hold for a while while we were dinking around at higher
> levels in WC-NG. Would others agree that at this point, we're a bit more
> free to start soliciting (and responding to) performance evaluations from
> the likes of TortoiseSVN, AnkhSVN, subclipse, etc.?
As a TSVN developer and user: +1 on that.
-- Stefan^2.
Re: 1.7 Roadmap Items Evaluation
Posted by Julian Foad <ju...@wandisco.com>.
On Mon, 2011-04-11, Noorul Islam K M wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
> > "Remove obliterate code": I think the obliterate code is all tucked away in
> > private functions and such at this point. Is that as far as we plan to take
> > this in 1.7? If not, the purge of this stuff would be some pretty
> > low-hanging fruit for a would-be contributor.
>
> I submitted a patch for this.
I committed this, tweaked to also remove three more functions, in
r1091717, and updated the roadmap web page in r1091718. As I said to
C-Mike on IRC, "I guess there's no harm deleting it. I guess if it was
somebody else's code I'd prefer that it would be deleted." I can easily
resurrect as much of it as is useful when the time comes to work on it
again.
- Julian
Re: 1.7 Roadmap Items Evaluation
Posted by Noorul Islam K M <no...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> "Remove obliterate code": I think the obliterate code is all tucked away in
> private functions and such at this point. Is that as far as we plan to take
> this in 1.7? If not, the purge of this stuff would be some pretty
> low-hanging fruit for a would-be contributor.
>
I submitted a patch for this.
Thanks and Regards
Noorul
Re: 1.7 Roadmap Items Evaluation
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Apr 07, 2011 at 11:19:48AM -0400, C. Michael Pilato wrote:
> "Externals": This one concerns me. The referenced issue (#3818) implies
> that we plan to completely rework our storage and handling of externals in
> the 1.7 timeframe. Further, there are references to regressions against
> 1.6.x, which would seem at first glance to prevent us from deferring until a
> future date. Can someone speak with confidence and knowledge about all of this?
Issue 3818 may be bogus. It needs more research.
I haven't had time to digest Greg's input regarding the issue I've
opened: http://svn.haxx.se/dev/archive-2011-02/0898.shtml
I'll be on-site at a customer all of next week, and then
busy preparing the workshop program for elego's SVN Day.
So I don't think I'll get to look at this before the Apache Retreat
in Ireland and the Berlin hackathon. If someone wants to pick up the ball,
please go ahead.
RE: 1.7 Roadmap Items Evaluation
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> Sent: woensdag 13 april 2011 11:48
> To: Julian Foad
> Cc: dev@subversion.apache.org
> Subject: Re: 1.7 Roadmap Items Evaluation
>
> On 13.04.2011 11:37, Julian Foad wrote:
> > On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
> >> On 12.04.2011 18:50, Julian Foad wrote:
> >>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
> >>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> >>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
> >>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs
> are
> >>>>>> private, so what's the penalty if they wind up in the release?
> >>>>> We'd have to support them privately for the rest of the 1.7.x line, due
> >>>>> to private ABI compatibility?
> >>>>>
> >>>>> http://article.gmane.org/gmane.comp.version-
> control.subversion.devel/125849
> >>>> Ah, okay. I didn't realize that we allowed mix-and-match of
> >>>> patch-level-differing-only versions.
> >>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
> >>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
> >>> internal APIs that are called from a different Subversion library, and
> >>> we won't need to preserve those through 1.7.x.
> >> Then you'd better change the version checking code in the libraries.
> > Please correct my understanding or ... wait a sec, this is already doc'd
> > in 'Hacking', so I'll go take a look and correct myself.
>
> Specifically, no library should be using svn_ver_check_list, but only
> svn_ver_equal, if what you say about library compatibility is true.
Our own code should use svn_ver_equal and third party code (which should only use public apis) should use svn_ver_check_list.
Bert
Re: 1.7 Roadmap Items Evaluation
Posted by Blair Zajac <bl...@orcaware.com>.
On Apr 14, 2011, at 2:19 AM, Julian Foad wrote:
> Blair Zajac wrote:
>> On 04/13/2011 03:17 AM, Julian Foad wrote:
>>> Branko Čibej wrote:
>>>> On 13.04.2011 11:37, Julian Foad wrote:
>>>>> On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
>>>>>> On 12.04.2011 18:50, Julian Foad wrote:
>>>>>>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
>>>>>>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
>>>>>>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>>>>>>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>>>>>>>>>> private, so what's the penalty if they wind up in the release?
>>>>>>>>> We'd have to support them privately for the rest of the 1.7.x line, due
>>>>>>>>> to private ABI compatibility?
>>>>>>>>>
>>>>>>>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
>>>>>>>> Ah, okay. I didn't realize that we allowed mix-and-match of
>>>>>>>> patch-level-differing-only versions.
>>>>>>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
>>>>>>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
>>>>>>> internal APIs that are called from a different Subversion library, and
>>>>>>> we won't need to preserve those through 1.7.x.
>>>>>> Then you'd better change the version checking code in the libraries.
>>>>> Please correct my understanding or ... wait a sec, this is already doc'd
>>>>> in 'Hacking', so I'll go take a look and correct myself.
>>>
>>> Are you saying we *do* support running a mixed set of Subversion
>>> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
>>> under the impression we had a policy of "you must upgrade (or downgrade)
>>> the libraries as a complete set, not individually".
>>
>> That's my understanding too, and IIRC, we've done this in the past with
> ----------------------------------------------------^^^^
> What's "this"?
Add, modify or remove private functions.
Blair
Re: 1.7 Roadmap Items Evaluation
Posted by Julian Foad <ju...@wandisco.com>.
Blair Zajac wrote:
> On 04/13/2011 03:17 AM, Julian Foad wrote:
> > Branko Čibej wrote:
> >> On 13.04.2011 11:37, Julian Foad wrote:
> >>> On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
> >>>> On 12.04.2011 18:50, Julian Foad wrote:
> >>>>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
> >>>>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> >>>>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
> >>>>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
> >>>>>>>> private, so what's the penalty if they wind up in the release?
> >>>>>>> We'd have to support them privately for the rest of the 1.7.x line, due
> >>>>>>> to private ABI compatibility?
> >>>>>>>
> >>>>>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
> >>>>>> Ah, okay. I didn't realize that we allowed mix-and-match of
> >>>>>> patch-level-differing-only versions.
> >>>>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
> >>>>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
> >>>>> internal APIs that are called from a different Subversion library, and
> >>>>> we won't need to preserve those through 1.7.x.
> >>>> Then you'd better change the version checking code in the libraries.
> >>> Please correct my understanding or ... wait a sec, this is already doc'd
> >>> in 'Hacking', so I'll go take a look and correct myself.
> >
> > Are you saying we *do* support running a mixed set of Subversion
> > libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
> > under the impression we had a policy of "you must upgrade (or downgrade)
> > the libraries as a complete set, not individually".
>
> That's my understanding too, and IIRC, we've done this in the past with
----------------------------------------------------^^^^
What's "this"?
> merges to release branches.
- Julian
Re: 1.7 Roadmap Items Evaluation
Posted by Blair Zajac <bl...@orcaware.com>.
On 04/13/2011 03:17 AM, Julian Foad wrote:
> Branko Čibej wrote:
>> On 13.04.2011 11:37, Julian Foad wrote:
>>> On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
>>>> On 12.04.2011 18:50, Julian Foad wrote:
>>>>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
>>>>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
>>>>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>>>>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>>>>>>>> private, so what's the penalty if they wind up in the release?
>>>>>>> We'd have to support them privately for the rest of the 1.7.x line, due
>>>>>>> to private ABI compatibility?
>>>>>>>
>>>>>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
>>>>>> Ah, okay. I didn't realize that we allowed mix-and-match of
>>>>>> patch-level-differing-only versions.
>>>>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
>>>>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
>>>>> internal APIs that are called from a different Subversion library, and
>>>>> we won't need to preserve those through 1.7.x.
>>>> Then you'd better change the version checking code in the libraries.
>>> Please correct my understanding or ... wait a sec, this is already doc'd
>>> in 'Hacking', so I'll go take a look and correct myself.
>
> Are you saying we *do* support running a mixed set of Subversion
> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
> under the impression we had a policy of "you must upgrade (or downgrade)
> the libraries as a complete set, not individually".
That's my understanding too, and IIRC, we've done this in the past with
merges to release branches.
Blair
Policy for running mixed-patch-number,same-minor-number libraries (was:
Re: 1.7 Roadmap Items Evaluation)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
(just changing the subject for greater visibility)
Re: 1.7 Roadmap Items Evaluation
Posted by Branko Čibej <br...@e-reka.si>.
On 13.04.2011 14:04, C. Michael Pilato wrote:
> On 04/13/2011 06:17 AM, Julian Foad wrote:
>> Are you saying we *do* support running a mixed set of Subversion
>> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
>> under the impression we had a policy of "you must upgrade (or downgrade)
>> the libraries as a complete set, not individually".
> As was I. [Insert disclaimers similar to Julian's here.]
I agree such a policy would be useful. But I can't find it in the
version compatibility guide. That said, I'd support adding such wording,
and relaxing the compat guidelines in general. They're useful, but have
turned out to be somewhat too restrictive in practice.
-- Brane
Re: 1.7 Roadmap Items Evaluation
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/13/2011 06:17 AM, Julian Foad wrote:
> Are you saying we *do* support running a mixed set of Subversion
> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
> under the impression we had a policy of "you must upgrade (or downgrade)
> the libraries as a complete set, not individually".
As was I. [Insert disclaimers similar to Julian's here.]
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7 Roadmap Items Evaluation
Posted by Julian Foad <ju...@wandisco.com>.
Branko Čibej wrote:
> On 13.04.2011 11:37, Julian Foad wrote:
> > On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
> >> On 12.04.2011 18:50, Julian Foad wrote:
> >>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
> >>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> >>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
> >>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
> >>>>>> private, so what's the penalty if they wind up in the release?
> >>>>> We'd have to support them privately for the rest of the 1.7.x line, due
> >>>>> to private ABI compatibility?
> >>>>>
> >>>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
> >>>> Ah, okay. I didn't realize that we allowed mix-and-match of
> >>>> patch-level-differing-only versions.
> >>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
> >>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
> >>> internal APIs that are called from a different Subversion library, and
> >>> we won't need to preserve those through 1.7.x.
> >> Then you'd better change the version checking code in the libraries.
> > Please correct my understanding or ... wait a sec, this is already doc'd
> > in 'Hacking', so I'll go take a look and correct myself.
Are you saying we *do* support running a mixed set of Subversion
libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
under the impression we had a policy of "you must upgrade (or downgrade)
the libraries as a complete set, not individually".
I can't find anything relevant in 'Hacking' ('Community Guide'). That
and the email referenced above only talk about "the libraries" as a
group.
> Specifically, no library should be using svn_ver_check_list, but only
> svn_ver_equal, if what you say about library compatibility is true.
The svn_ver_compatible() / svn_ver_check_list() / svn_ver_equal() APIs
are only used where we are loading optional libraries (FS, RA and
authz).
The other libraries have no version checks explicitly coded into them as
far as I can see. I assume therefore that the version compatibility
rules are defined by our policy (and to some limited extent enforced by
code), not that there are no restrictions to mixing libraries of
different versions beyond what is enforced in code.
But I'm no expert in versioning or what we may have decided in the past.
(I couldn't find any relevant emails with a quick bit of Googling.)
- Julian
Re: 1.7 Roadmap Items Evaluation
Posted by Branko Čibej <br...@e-reka.si>.
On 13.04.2011 11:37, Julian Foad wrote:
> On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
>> On 12.04.2011 18:50, Julian Foad wrote:
>>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
>>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
>>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>>>>>> private, so what's the penalty if they wind up in the release?
>>>>> We'd have to support them privately for the rest of the 1.7.x line, due
>>>>> to private ABI compatibility?
>>>>>
>>>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
>>>> Ah, okay. I didn't realize that we allowed mix-and-match of
>>>> patch-level-differing-only versions.
>>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
>>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
>>> internal APIs that are called from a different Subversion library, and
>>> we won't need to preserve those through 1.7.x.
>> Then you'd better change the version checking code in the libraries.
> Please correct my understanding or ... wait a sec, this is already doc'd
> in 'Hacking', so I'll go take a look and correct myself.
Specifically, no library should be using svn_ver_check_list, but only
svn_ver_equal, if what you say about library compatibility is true.
-- Brane
Re: 1.7 Roadmap Items Evaluation
Posted by Julian Foad <ju...@wandisco.com>.
On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
> On 12.04.2011 18:50, Julian Foad wrote:
> > On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
> >> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> >>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
> >>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
> >>>> private, so what's the penalty if they wind up in the release?
> >>> We'd have to support them privately for the rest of the 1.7.x line, due
> >>> to private ABI compatibility?
> >>>
> >>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
> >> Ah, okay. I didn't realize that we allowed mix-and-match of
> >> patch-level-differing-only versions.
> > Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
> > libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
> > internal APIs that are called from a different Subversion library, and
> > we won't need to preserve those through 1.7.x.
>
> Then you'd better change the version checking code in the libraries.
Please correct my understanding or ... wait a sec, this is already doc'd
in 'Hacking', so I'll go take a look and correct myself.
- Julian
Re: 1.7 Roadmap Items Evaluation
Posted by Branko Čibej <br...@e-reka.si>.
On 12.04.2011 18:50, Julian Foad wrote:
> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>>>> private, so what's the penalty if they wind up in the release?
>>> We'd have to support them privately for the rest of the 1.7.x line, due
>>> to private ABI compatibility?
>>>
>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
>> Ah, okay. I didn't realize that we allowed mix-and-match of
>> patch-level-differing-only versions.
> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
> internal APIs that are called from a different Subversion library, and
> we won't need to preserve those through 1.7.x.
Then you'd better change the version checking code in the libraries.
-- Brane
Re: 1.7 Roadmap Items Evaluation
Posted by Julian Foad <ju...@wandisco.com>.
On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
> >> "Remove temp APIs": I would put this at "nice to have". These APIs are
> >> private, so what's the penalty if they wind up in the release?
> >
> > We'd have to support them privately for the rest of the 1.7.x line, due
> > to private ABI compatibility?
> >
> > http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
>
> Ah, okay. I didn't realize that we allowed mix-and-match of
> patch-level-differing-only versions.
Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
internal APIs that are called from a different Subversion library, and
we won't need to preserve those through 1.7.x.
The only APIs we'd need to preserve would be ones that may be called by
clients, and by definition that shouldn't include any that we regard as
"private". If we have allowed the "svn" client to call some private
APIs, that's what we need to fix before release.
Please correct me if I'm wrong.
- Julian
Re: 1.7 Roadmap Items Evaluation
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>> private, so what's the penalty if they wind up in the release?
>
> We'd have to support them privately for the rest of the 1.7.x line, due
> to private ABI compatibility?
>
> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
Ah, okay. I didn't realize that we allowed mix-and-match of
patch-level-differing-only versions.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7 Roadmap Items Evaluation
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
> "Remove temp APIs": I would put this at "nice to have". These APIs are
> private, so what's the penalty if they wind up in the release?
We'd have to support them privately for the rest of the 1.7.x line, due
to private ABI compatibility?
http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
Re: 1.7 Roadmap Items Evaluation
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/07/2011 11:57 AM, Ivan Zhakov wrote:
> On Thu, Apr 7, 2011 at 19:19, C. Michael Pilato <cm...@collab.net> wrote:
>>
>> "libsvn_ra_serf stabilization": Ivan and others have made progress in this
>> space, and AFAIK the Serf project has made the "new public release of serf
>> which contains the fix for the massive SSL memory leak" that we call for.
>> What's left?
>>
> Memory usage of checkout/update/export is real problem in ra_serf. The
> problem comes from usage of skelta update editor mode.
>
> Lieven has some ideas how to overcome this problem [1]. While my
> personal opinion that easiest way is to implement non-skelta update
> editor mode in ra_serf (the same way as ra_neon does).
>
> [1] http://groups.google.com/group/subversion-development/browse_thread/thread/b70da726df62fa4a
>
I confess that, for reasons noted by Mark Phippard in his recent mail[1]
about ra_serf performance, I lean toward implementing the non-skelta mode.
I wouldn't even mind it if that behavior was client-side configurable, but
definitely defaulting to non-skelta.
-- C-Mike
[1] http://svn.haxx.se/dev/archive-2011-03/0728.shtml
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7 Roadmap Items Evaluation
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 7, 2011 at 11:57, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Thu, Apr 7, 2011 at 19:19, C. Michael Pilato <cm...@collab.net> wrote:
>>
>> "libsvn_ra_serf stabilization": Ivan and others have made progress in this
>> space, and AFAIK the Serf project has made the "new public release of serf
>> which contains the fix for the massive SSL memory leak" that we call for.
>> What's left?
>>
> Memory usage of checkout/update/export is real problem in ra_serf. The
> problem comes from usage of skelta update editor mode.
>
> Lieven has some ideas how to overcome this problem [1]. While my
> personal opinion that easiest way is to implement non-skelta update
> editor mode in ra_serf (the same way as ra_neon does).
>
> [1] http://groups.google.com/group/subversion-development/browse_thread/thread/b70da726df62fa4a
I would strongly suggest that we NOT attempt to rebuild the update
mechanism in ra_serf at this late stage. I can understand the
pragmatic desire (eg. efficiency for many small files), I think that
is a discuss best reserved for post-1.7.
It seems that Lieven is on the right path with a fix, so maybe some
extra tweaking will make that happen.
Cheers,
-g
Re: 1.7 Roadmap Items Evaluation
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Apr 7, 2011 at 19:19, C. Michael Pilato <cm...@collab.net> wrote:
>
> "libsvn_ra_serf stabilization": Ivan and others have made progress in this
> space, and AFAIK the Serf project has made the "new public release of serf
> which contains the fix for the massive SSL memory leak" that we call for.
> What's left?
>
Memory usage of checkout/update/export is real problem in ra_serf. The
problem comes from usage of skelta update editor mode.
Lieven has some ideas how to overcome this problem [1]. While my
personal opinion that easiest way is to implement non-skelta update
editor mode in ra_serf (the same way as ra_neon does).
[1] http://groups.google.com/group/subversion-development/browse_thread/thread/b70da726df62fa4a
--
Ivan Zhakov
Re: 1.7 Roadmap Items Evaluation
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 7, 2011 at 11:19, C. Michael Pilato <cm...@collab.net> wrote:
> I'm looking at a number of things right now, trying to get a handle on
> exactly where 1.7 is in its slow trek towards completion. Obviously, we
Thanks, Mike.
>...
> "Externals": This one concerns me. The referenced issue (#3818) implies
> that we plan to completely rework our storage and handling of externals in
> the 1.7 timeframe. Further, there are references to regressions against
> 1.6.x, which would seem at first glance to prevent us from deferring until a
> future date. Can someone speak with confidence and knowledge about all of this?
Don't know the status on this, but I'd suggest that we try to defer
any reworking to post-1.7 (unless we must to fix regressions or bugs).
> "Remove obliterate code": I think the obliterate code is all tucked away in
> private functions and such at this point. Is that as far as we plan to take
> this in 1.7? If not, the purge of this stuff would be some pretty
> low-hanging fruit for a would-be contributor.
I would have said "leave it in there", but Julian accepted Noorul's
patch... so I'm guessing he may have other ideas for when we return to
this, rather than leaving that code still in there.
>...
> "libsvn_ra_serf stabilization": Ivan and others have made progress in this
> space, and AFAIK the Serf project has made the "new public release of serf
> which contains the fix for the massive SSL memory leak" that we call for.
> What's left?
Nothing that I'm aware of. Just a normal level of bug fixes. There is
a suggestion later-thread around ra_serf, which I'll address there.
>...
> "Remove temp APIs": I would put this at "nice to have". These APIs are
> private, so what's the penalty if they wind up in the release?
Leave them, I say. There is more on this later-thread, and I'll
address it there.
They might not be ideal, but they are *private*, so we can revamp them
and fix them and make them our bitch in the future. I see no problem
shipping them in 1.7 as-is.
>...
Cheers,
-g