It was normalization: it makes the separation consistent with the
functions immediately above/below it in the file.
Greg Stein wrote on Wed, Feb 15, 2012 at 01:19:33 -0500:
> Since single blank lines are commonplace throughout our code/functions, I
> do like to use double-blank to separate functio
Since single blank lines are commonplace throughout our code/functions, I
do like to use double-blank to separate functions. Visually, it works well
to separate functions (or other semantic entities that typically contain
single blanks).
Maybe in this case, the file was using single-blank between
Can someone test this on Windows please? The test should XFAIL against
1.7/trunk and XPASS against 1.6.
As an aside, the repeated self.ospath() calls can't be terribly
efficient --- they will call os.path.join() repeatedly --- but, insofar
as that is a problem, I reckon the Sandbox class's API co
On Mon, Feb 13, 2012 at 12:05 PM, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Feb 13, 2012 at 17:52:01 +0100:
>> On 13.02.2012 17:09, Daniel Shahaf wrote:
>> > Thanks for your thoughts. One comment:
>> >
>> > Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100:
>> >> The idea is that
On 14.02.2012 14:53, Philip Martin wrote:
> Philip Martin writes:
>
>> Branko Čibej writes:
>>
>>> Please explain again, why do we need the revved _ensure2 at all? Can you
>>> think of any possible way that even marginally sane code would break if
>>> we just fixed the docs and behaviour of _ensu
On Feb 14, 2012 8:54 AM, "Philip Martin" wrote:
>
> Philip Martin writes:
>
> > Branko Čibej writes:
> >
> >> Please explain again, why do we need the revved _ensure2 at all? Can
you
> >> think of any possible way that even marginally sane code would break if
> >> we just fixed the docs and beha
Philip Martin writes:
> Still it's hard to ignore the performance gain. Perhaps we could make
> it (whispers) configurable?
Here's a simple Linux LD_PRELOAD version of the patch. Build it as a
shared library and then the feature can be enabled on any given svn
invocation by setting the environ
"C. Michael Pilato" writes:
> On 02/14/2012 05:41 AM, Philip Martin wrote:
>> A substantial performance improvement but at the cost of making write
>> operations block read operations. This would mean things like TSVN
>> would not be able to run status on a working copy while its checkout was
>>
On 02/14/2012 05:41 AM, Philip Martin wrote:
> A substantial performance improvement but at the cost of making write
> operations block read operations. This would mean things like TSVN
> would not be able to run status on a working copy while its checkout was
> running.
Just to clarify, by "chec
Philip Martin writes:
> Branko Čibej writes:
>
>> Please explain again, why do we need the revved _ensure2 at all? Can you
>> think of any possible way that even marginally sane code would break if
>> we just fixed the docs and behaviour of _ensure?
>
> I was thinking the same. What would break
Branko Čibej writes:
> On 14.02.2012 13:26, Julian Foad wrote:
>> For review, please.
>>
>> We discovered some bugs recently [1,2] with use of svn_string.h functions,
>> where space for the terminating null character was sometimes not being
>> allocated. The attached patch file contains severa
Branko Čibej wrote:
> Julian Foad wrote:
>> We discovered some bugs recently [1,2] with use of svn_string.h functions,
>> where space for the terminating null character was sometimes not being
>> allocated. [...]
>>
>> * Introduce revved API svn_stringbuf_ensure2() that promises to make
>>
On 14.02.2012 13:26, Julian Foad wrote:
> For review, please.
>
> We discovered some bugs recently [1,2] with use of svn_string.h functions,
> where space for the terminating null character was sometimes not being
> allocated. The attached patch file contains several changes in this area,
> whi
I (Julian Foad) wrote:
> I suggest we follow up by doing both of:
>
> * Change the implementation to always add an extra byte to that requested,
> to
> help buggy callers. This is valid because the number passed in is already
> only
> a lower bound so callers can't assume that we don't inc
Stefan Fuhrmann wrote:
> [...] As already discussed on IRC, the real cause here
> is that _ensure() should follow the first invariant listed
> in svn_string.h by allocating *additional* space for
> the terminating 0. In particular svn_stringbuf_ensure()
> is inconsistent with svn_stringbuf_create_
For review, please.
We discovered some bugs recently [1,2] with use of svn_string.h functions,
where space for the terminating null character was sometimes not being
allocated. The attached patch file contains several changes in this area,
which are all somewhat together although I'll commit t
Thanks Julian and Markus for providing feedback.
I am not commenting below because all the feedback is very good and I will try
to address it as best I can in the next iteration. Describing the behaviour
changes to the WC is the most challenging since I lack that kind of detailed
knowledge. I
[Apologies for a second email, original ISP is experiencing email delays]
WCNG has poor performance when the working copy is on an NFS, or other
network disk. Subversion has always been significantly slower with
working copies on network, rather than local disks, but 1.7 is worse
than 1.6. I bel
WCNG has poor performance when the working copy is on an NFS, or other
network disk. Subversion has always been significantly slower with
working copies on network, rather than local disks, but 1.7 is worse
than 1.6. I believe 1.7 performance is dominated by SQLite transaction
overhead, and that
Hi Thomas. It's fantastic that you're taking the trouble to write up this
proposal. That's just what we need. Just a few initial comments below...
Thomas Åkesson wrote:
> Context
> ===
>
> [...] A unicode string (e.g. a file name) can be represented
> in 2 normalized forms (NFC/NFD) or mixed
Hi, Thomas,
Just a little bit of nitpicking: For some characters, there exist more than 2
different ways: Sometimes, there are different codepoints for the same
character, or characters can be partially composed or they can be decomposed,
but with non-canonical ordering. Those cases are rare in
Greg Stein wrote:
> We have Ev2 somewhere on the future horizon. [...]
> I'd like to go ahead and deprecate the
> appropriate interfaces in svn_wc. [...]
>
> I'd like to do the deprecation now, rather than later. There isn't any
> particular technical reason, but Julian phrased it best: engineerin
22 matches
Mail list logo
