On 02/18/2011 09:23 AM, Stefan Küng wrote:
> I wanted to avoid this, but if you remember we've had this discussion
> before. I requested that the new status API would return information that
> the deprecated one did too. And the very first answer I got was that even
> "the scan if the file has been
On 18.02.2011 14:37, C. Michael Pilato wrote:
On 02/18/2011 06:42 AM, Stefan Küng wrote:
On 17.02.2011 14:19, Hyrum K Wright wrote:
Last summer in Berlin we had a quite heated discussion about just
deprecating all of libsvn_wc APIs. I was against such a move (at
least until 2.0) in that it w
On 02/18/2011 06:42 AM, Stefan Küng wrote:
> On 17.02.2011 14:19, Hyrum K Wright wrote:
>
>>
>> Last summer in Berlin we had a quite heated discussion about just
>> deprecating all of libsvn_wc APIs. I was against such a move (at
>> least until 2.0) in that it would leave the existing APIs publi
On Fri, Feb 18, 2011 at 12:42:30PM +0100, Stefan Küng wrote:
> On 17.02.2011 14:19, Hyrum K Wright wrote:
>
> >
> >Last summer in Berlin we had a quite heated discussion about just
> >deprecating all of libsvn_wc APIs. I was against such a move (at
> >least until 2.0) in that it would leave the e
On 17.02.2011 14:19, Hyrum K Wright wrote:
Last summer in Berlin we had a quite heated discussion about just
deprecating all of libsvn_wc APIs. I was against such a move (at
least until 2.0) in that it would leave the existing APIs public, but
any new ones private, and the whole interface in l
I concur with all of Mike's statements here. I see no reason to
believe that we'll *ever* see any intention of pluggable working copy
libraries.
On Thu, Feb 17, 2011 at 09:22, C. Michael Pilato wrote:
> On 02/17/2011 08:17 AM, Branko Čibej wrote:
>> On 17.02.2011 14:12, Stefan Sperling wrote:
>>>
On 02/17/2011 08:19 AM, Hyrum K Wright wrote:
> Without having looked at that code recently, I think this is the right
> strategy. If the APIs are useful outside of Subversion, let's expose
> 'em publicly, instead of making those consumers feel like second-class
> citizens.
>
>
> Last summer in
On 02/17/2011 08:17 AM, Branko Čibej wrote:
> On 17.02.2011 14:12, Stefan Sperling wrote:
>> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>>> On 17.02.2011 13:39, Julian Foad wrote:
Let me point out the background, in case you weren't aware. There has
been a general feel
On Thu, Feb 17, 2011 at 02:17:16PM +0100, Branko Čibej wrote:
> With a sane, useful public WC API you can at least think about plugging
> different WC backends ... someday. Same goes for the repos/fs separation.
I'd say doing this now is premature optimisation.
Especially because wc-ng isn't done
On 17.02.2011 13:39, Julian Foad wrote:
On Thu, 2011-02-17, Stefan Sperling wrote:
On Thu, Feb 17, 2011 at 12:47:32PM +0100, Stefan Küng wrote:
Hi,
The new function svn_wc__prop_list_recursive() provides a big
performance gain for listing all properties of a full working copy.
Currently I have
2011/2/17 Branko Čibej :
> On 17.02.2011 12:47, Stefan Küng wrote:
>> Hi,
>>
>> The new function svn_wc__prop_list_recursive() provides a big
>> performance gain for listing all properties of a full working copy.
>> Currently I have to use svn_client_proplist3() to make use of that.
>>
>> But I'd l
On 17.02.2011 14:12, Stefan Sperling wrote:
> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>> On 17.02.2011 13:39, Julian Foad wrote:
>>> Let me point out the background, in case you weren't aware. There has
>>> been a general feeling (especially during the WC re-write) that the W
On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
> On 17.02.2011 13:39, Julian Foad wrote:
> > Let me point out the background, in case you weren't aware. There has
> > been a general feeling (especially during the WC re-write) that the WC
> > API wasn't well suited to being maintaine
On 17.02.2011 13:39, Julian Foad wrote:
> Let me point out the background, in case you weren't aware. There has
> been a general feeling (especially during the WC re-write) that the WC
> API wasn't well suited to being maintained as a public API and that we
> should move in the direction of provid
On 17.02.2011 12:47, Stefan Küng wrote:
> Hi,
>
> The new function svn_wc__prop_list_recursive() provides a big
> performance gain for listing all properties of a full working copy.
> Currently I have to use svn_client_proplist3() to make use of that.
>
> But I'd like to have that API accessible di
On Thu, 2011-02-17, Stefan Sperling wrote:
> On Thu, Feb 17, 2011 at 12:47:32PM +0100, Stefan Küng wrote:
> > Hi,
> >
> > The new function svn_wc__prop_list_recursive() provides a big
> > performance gain for listing all properties of a full working copy.
> > Currently I have to use svn_client_pro
On Thu, Feb 17, 2011 at 12:47:32PM +0100, Stefan Küng wrote:
> Hi,
>
> The new function svn_wc__prop_list_recursive() provides a big
> performance gain for listing all properties of a full working copy.
> Currently I have to use svn_client_proplist3() to make use of that.
>
> But I'd like to have
Hi,
The new function svn_wc__prop_list_recursive() provides a big
performance gain for listing all properties of a full working copy.
Currently I have to use svn_client_proplist3() to make use of that.
But I'd like to have that API accessible directly, the same way e.g.
svn_wc_prop_list2().
18 matches
Mail list logo
