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: engineering
at
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
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,
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
[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
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
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
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
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 increase
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,
which
Branko Čibej br...@apache.org 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
Philip Martin philip.mar...@wandisco.com writes:
Branko Čibej br...@apache.org 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
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 checkout
C. Michael Pilato cmpil...@collab.net 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
Philip Martin philip.mar...@wandisco.com 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
On Feb 14, 2012 8:54 AM, Philip Martin philip.mar...@wandisco.com wrote:
Philip Martin philip.mar...@wandisco.com writes:
Branko Čibej br...@apache.org writes:
Please explain again, why do we need the revved _ensure2 at all? Can
you
think of any possible way that even marginally sane
On 14.02.2012 14:53, Philip Martin wrote:
Philip Martin philip.mar...@wandisco.com writes:
Branko Čibej br...@apache.org 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
On Mon, Feb 13, 2012 at 12:05 PM, Daniel Shahaf d...@daniel.shahaf.name 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
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
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
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
21 matches
Mail list logo
