woot!
I'll be there, most definitely!
On Mon, Oct 4, 2010 at 09:45, C. Michael Pilato wrote:
> For those who don't know, ApacheCon North America comes to Atlanta, GA,
> November 1-5 this year. You can find out more about the conference via the
> official conference website at http://na.apacheco
On 10/15/2010 05:26 PM, Bob Archer wrote:
- cold cache: 1.7 is almost 50% faster than 1.6
1.7: 22s
1.6: 42s
- hot cache: 1.7 is just about on par with 1.6 (only 20% slower)
1.7: 0.86s
1.6: 0.72s
>>>
>>> What do you guys mean by "cold cache" and "hot cache"? I
> >> - cold cache: 1.7 is almost 50% faster than 1.6
> >> 1.7: 22s
> >> 1.6: 42s
> >>
> >> - hot cache: 1.7 is just about on par with 1.6 (only 20% slower)
> >> 1.7: 0.86s
> >> 1.6: 0.72s
> >>
> >
> > What do you guys mean by "cold cache" and "hot cache"? If they
> mean what I think they mean, woul
>> - cold cache: 1.7 is almost 50% faster than 1.6
>> 1.7: 22s
>> 1.6: 42s
>>
>> - hot cache: 1.7 is just about on par with 1.6 (only 20% slower)
>> 1.7: 0.86s
>> 1.6: 0.72s
>>
>
> What do you guys mean by "cold cache" and "hot cache"? If they mean what I
> think they mean, wouldn't "hot cache" be
> On Fri, Oct 15, 2010 at 4:19 PM, wrote:
> > Author: philip
> > Date: Fri Oct 15 14:19:36 2010
> > New Revision: 1022931
> >
> > URL: http://svn.apache.org/viewvc?rev=1022931&view=rev
> > Log:
> > Implement status using per-dir queries. On my machine (Linux,
> local
> > disk) this improves the
On Fri, Oct 15, 2010 at 4:19 PM, wrote:
> Author: philip
> Date: Fri Oct 15 14:19:36 2010
> New Revision: 1022931
>
> URL: http://svn.apache.org/viewvc?rev=1022931&view=rev
> Log:
> Implement status using per-dir queries. On my machine (Linux, local
> disk) this improves the speed of status on a
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 14 oktober 2010 23:39
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1022707 - in /subversion/trunk: ./
> subversion/libsvn_subr/io.c
>
> On Thu, Oct 14, 2010 at 09:00:44PM -, hwri...@a
On 15.10.2010 15:06, Hyrum K. Wright wrote:
> (I hope our C docs point this out explicitly, too.)
If not, you're bound to find out sooner or later. :)
-- Brane
On Fri, Oct 15, 2010 at 4:35 AM, Branko Čibej wrote:
> On 14.10.2010 20:39, Hyrum K. Wright wrote:
>> The following is a somewhat naïve implementation, but does it jive
>> with your suggestion?
>
> Roughly yes, see the other comment.
> On reflection, though, I like the suggestion of returning an
On 15.10.2010 12:22, Johan Corveleyn wrote:
> On Fri, Oct 15, 2010 at 12:20 PM, Johan Corveleyn wrote:
>> I saw that the problem was fixed in r102170 by Bert
> s/r102170/r1021760/
>
> I really should install that "Undo send" google labs extension :)
I saw they also have a beta of "delete from in
On Fri, Oct 15, 2010 at 12:20 PM, Johan Corveleyn wrote:
> I saw that the problem was fixed in r102170 by Bert
s/r102170/r1021760/
I really should install that "Undo send" google labs extension :)
--
Johan
On Sun, Oct 10, 2010 at 3:07 PM, Johan Corveleyn wrote:
> On Sat, Oct 2, 2010 at 11:24 AM, Bert Huijben wrote:
>>> -Original Message-
>>> From: Paul Burba [mailto:ptbu...@gmail.com]
>>> Sent: vrijdag 1 oktober 2010 15:46
>>> To: Bert Huijben
>>> Cc: Johan Corveleyn; Subversion Development
> Steinar Bang :
> Philipp Marek :
>> It might be easier for callers if this did
>> if (isNull)
>> return "";
>> so that the value could just be used in printf() and similar without
>> explicit checking.
> If that was ok to do, one might as well represent a NULL with an empty
> string.
> Branko Čibej :
> std::string also doesn't have any virtual functions, nor does a bool
> member require a destructor. Memory deallocation is OK. std::string is
> actually a POD and tricky rules apply that allow you do do this
> safely, IIRC ...
Nevertheless, deleting a derived object from a
On 14.10.2010 20:39, Hyrum K. Wright wrote:
> The following is a somewhat naïve implementation, but does it jive
> with your suggestion?
Roughly yes, see the other comment.
On reflection, though, I like the suggestion of returning an
std::pair. Make a typedef of that so that users can
declare ret
On 14.10.2010 20:39, Hyrum K. Wright wrote:
> inline operator bool() const
> {
> return !isNull;
> }
This bit seriously changes the semantics of std::string. I recommend not
to override operator bool() like this. Write a different accessor
function instead.
-- Brane
On 14.10.2010 21:32, Steinar Bang wrote:
>> Branko Čibej :
>> All right. Then derive svn::string from std::string, and add a .null()
>> method. You get to use all the standard string alogorithm
>> specializations, plus you get what you want.
> There is one known objection to this: std::string
Greg Stein wrote:
> Seems fine.
Thanks. Committed revision 1022862.
- Julian
> On Thu, Oct 14, 2010 at 18:32, Julian Foad wrote:
> > Hi Bert.
> >
> > Any objection to me simplifying start_directory_update_txn(), as in the
> > attached patch? It appears that it's doing relatively a lot of wor
Ramkumar Ramachandra writes:
> Hi Philip,
>
> [sorry about the delayed reply: I had a bad internet connection]
>
> Philip Martin writes:
>> If we are going to use the APR atomic interface then the two reads
>> should use apr_atomic_read32.
>>
>> It would be better to use svn_atomic__init_once.
> Philipp Marek :
> It might be easier for callers if this did
> if (isNull)
> return "";
> so that the value could just be used in printf() and similar without
> explicit checking.
If that was ok to do, one might as well represent a NULL with an empty
string.
20 matches
Mail list logo
