On Wed, Mar 02, 2011 at 08:31:01AM +, Neil Bird wrote:
> Around about 01/03/11 17:13, Stefan Sperling typed ...
> >Great! Here's a new version that includes a fix for the lock_tests
> >failures. I'll propose this for backport now. Thanks for providing
> >the initial patch submission for this an
Around about 01/03/11 17:13, Stefan Sperling typed ...
Great! Here's a new version that includes a fix for the lock_tests
failures. I'll propose this for backport now. Thanks for providing
the initial patch submission for this and for helping with testing!
Yep, that's the kiddie! Thanks for
On Tue, Mar 01, 2011 at 04:43:47PM +, Neil Bird wrote:
> Around about 01/03/11 16:34, Stefan Sperling typed ...
> >It's not perfect yet. There are regression test failures around
> >setting file permissions for svn:needs-lock and svn:executable.
>
> Yes, I saw those.
>
>
> >But the most in
Around about 01/03/11 16:34, Stefan Sperling typed ...
It's not perfect yet. There are regression test failures around
setting file permissions for svn:needs-lock and svn:executable.
Yes, I saw those.
But the most interesting bit of information is whether it fixes
the performance issues, w
Around about 01/03/11 16:03, Stefan Sperling typed ...
Neil, can you try the attached patch, please? Thanks!
Running all tests in lock_tests.py [57/71]...FAILURE
FAIL: lock_tests.py 25: svn:needs-lock and svn:executable, part I
FAIL: lock_tests.py 26: svn:needs-lock and svn:executable, part I
On Tue, Mar 01, 2011 at 04:08:30PM +, Neil Bird wrote:
> Around about 01/03/11 16:03, Stefan Sperling typed ...
> >Neil, can you try the attached patch, please? Thanks!
>
> OK, are you just trying to embarrass me now by getting an
> alternative patch out so quickly?? :-)
Heh. No, that's no
Around about 01/03/11 16:03, Stefan Sperling typed ...
Neil, can you try the attached patch, please? Thanks!
OK, are you just trying to embarrass me now by getting an alternative
patch out so quickly?? :-)
I'll try it now ...
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signa
Around about 01/03/11 15:19, Daniel Shahaf typed ...
The magic is "add 840074 to the old revnum to get the new one":
http://svn.apache.org/repos/asf/subversion/README
Ah, all is clear[er].
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or direct
On Tue, Mar 01, 2011 at 04:42:28PM +0100, Stefan Sperling wrote:
> I will try backporting the trunk code to 1.6.x myself.
> If that gets anywhere then we can use it.
Neil, can you try the attached patch, please? Thanks!
Index: subversion/libsvn_subr/io.c
===
On Tue, Mar 01, 2011 at 02:01:34PM +, Neil Bird wrote:
> Around about 08/02/11 10:01, Neil Bird typed ...
> Just to re-iterate, what I've done is change
> svn_io_open_unique_file3() so that instead of just calling
> svn_io_open_uniquely_named() it is in fact a verbatim copy of
> svn_io_open_u
Quick reply to address just this one point:
Neil Bird wrote on Tue, Mar 01, 2011 at 14:01:34 +:
> All that added to the fact that the revision numbers seem to have
> all changed (the move from Tigris to Apache?), so even when the
> comments *do* say that they're fixing blah from rev. xxx, th
Around about 08/02/11 10:01, Neil Bird typed ...
Around about 08/02/11 09:03, Daniel Shahaf typed ...
Thanks. However, to clarify, I'm not specifically interested in the
"give us N revisions" form; I'm just interested in seeing a coherent
patch at the end, and wanted to ensure you haven't forgot
Neil Bird wrote on Tue, Feb 08, 2011 at 08:39:04 +:
> Around about 08/02/11 01:58, Daniel Shahaf typed ...
>> I'm concerned; that doesn't sound like a good process to develop
>> a patch. Normally backporting a patch is a matter of finding
>> N applicable revisions and merging them... but it so
Around about 08/02/11 01:58, Daniel Shahaf typed ...
I'm concerned; that doesn't sound like a good process to develop
a patch. Normally backporting a patch is a matter of finding
N applicable revisions and merging them... but it sounds that here
you're re-developing the feature from scratch.
Neil Bird wrote on Fri, Feb 04, 2011 at 12:53:31 +:
> Around about 04/02/11 12:06, Neil Bird typed ...
> >It's turning out to be the PITA I expected.
>
> OK, I've backported enough of the trunk copy to get it compiling
> for Linux, but it now fails 2 tests. I'll investigate next week.
> It
Neil Bird wrote:
> Around about 04/02/11 10:52, Stefan Fuhrmann typed ...
> >> I'll give it another bash, though , if you think it's worth it.
> >>
> > Definitely. It contains quite a number of file access
> > optimizations that should become best visible on
> > "high overhead" FS like NTFS.
>
>
Around about 04/02/11 12:06, Neil Bird typed ...
It's turning out to be the PITA I expected.
OK, I've backported enough of the trunk copy to get it compiling for
Linux, but it now fails 2 tests. I'll investigate next week. It almost
certainly won't compile for Windows, either, as there's
Around about 04/02/11 10:52, Stefan Fuhrmann typed ...
I'll give it another bash, though , if you think it's worth it.
Definitely. It contains quite a number of file access
optimizations that should become best visible on
"high overhead" FS like NTFS.
It's turning out to be the PITA I expec
On 04.02.2011 09:08, Neil Bird wrote:
Around about 03/02/11 17:01, Stefan Sperling typed ...
* subversion/libsvn_subr/io.c
svn_io_open_unique_file3: don't call svn_io_open_uniquely_named(),
but instead use a copy of that routine
Which routine, precisely?
svn_io_open_uniquely_named(); so
Around about 03/02/11 17:01, Stefan Sperling typed ...
* subversion/libsvn_subr/io.c
svn_io_open_unique_file3: don't call svn_io_open_uniquely_named(),
but instead use a copy of that routine
Which routine, precisely?
svn_io_open_uniquely_named(); sorry, I thought that was clear enough.
On Thu, Feb 03, 2011 at 04:18:32PM +, Neil Bird wrote:
>
> This is a patch for discussion which I submitted to issue 3719
> (“Extremely slow checkout on Windows”). I shan't repeat everything
> that's there; essentially it fixes *really* slow checkouts to NTFS
> of directories with large nu
This is a patch for discussion which I submitted to issue 3719
(“Extremely slow checkout on Windows”). I shan't repeat everything that's
there; essentially it fixes *really* slow checkouts to NTFS of directories
with large numbers of files with properties.
I originally modified it sli
22 matches
Mail list logo
