On Tue, Apr 29, 2014 at 6:14 AM, Philip Martin
wrote:
> Branko Čibej writes:
>
>> We made a conscious decision
>> to design a working copy format that's faster than the old format could
>> ever have been and can better support new features (such as client-side
>> move tracking), at the expense of
Branko Čibej writes:
> We made a conscious decision
> to design a working copy format that's faster than the old format could
> ever have been and can better support new features (such as client-side
> move tracking), at the expense of poorer performance on a remote
> filesystem that is, when you
Guten Tag Florian Ludwig,
am Mittwoch, 16. April 2014 um 19:13 schrieben Sie:
> After disabling all those and running a test
> checkout on Linux and Windows on the same machine I still get a
> result of Linux being 7.3x times faster. Any ideas why?
I may have missed them but some things to co
On 4/28/14, 8:41 AM, Les Mikesell wrote:
> There's no concurrent access happening - just home directories where a
> user will be working on one machine or another - which is mostly
> transparent to normal applications.. Should there be a difference if
> they work on the server hosting the exported
On Mon, Apr 28, 2014 at 10:23 AM, Branko Čibej wrote:
>
> "Mostly read-only" would be a pretty good description of mature
> project maintenance - which in my experience is where most developer
> time goes.
>
>
> You're confusing the contents of versioned files with working copy metadata.
> The lat
On 28.04.2014 17:06, Les Mikesell wrote:
> On Fri, Apr 25, 2014 at 11:58 PM, Branko Čibej wrote:
>> "Mostly read-only" would be a pretty good description of mature
>> project maintenance - which in my experience is where most developer
>> time goes.
>>
>>
>> You're confusing the contents of versio
On Fri, Apr 25, 2014 at 11:58 PM, Branko Čibej wrote:
> >
> "Mostly read-only" would be a pretty good description of mature
> project maintenance - which in my experience is where most developer
> time goes.
>
>
> You're confusing the contents of versioned files with working copy metadata.
> The l
On Sat, Apr 26, 2014 at 5:02 PM, Roman Naumenko wrote:
> But git clients are doing pretty good on nfs, no?
git performance, and working copy consistency, is a wholde different
kettle of fish than subversion.
Branko Čibej said the following, on 25-04-14, 4:26 PM:
On 25.04.2014 19:09, Roman Naumenko wrote:
That was a known consequence of moving to SQLite for storage of the
metadata. SVN 1.8 offers a solution for those that can use it:
http://subversion.apache.org/docs/release-notes/1.8.html#exclusivel
On 26.04.2014 00:51, Les Mikesell wrote:
> On Fri, Apr 25, 2014 at 4:34 PM, Branko Čibej wrote:
>
>> To stray off topic for a minute here, though: the idea that working copies
>> are "cheap throwaway stuff" is less than universally true. I've seen complex
>> sparse working copies with many gigabyt
On 4/24/14, 6:40 PM, Roman Naumenko wrote:
> And nfs as well, please (sorry for hijacking the thread).
>
> Perfomance on nfs is just terrible (for all svn client versions).
> Take any linux box, checkout to local fs and checkout to nfs vol: you gonna be
> amazed.
>
> The nfs thing should be a big
On Fri, Apr 25, 2014 at 4:34 PM, Branko Čibej wrote:
>
> Working copies are supposed to be throwaway things that can always be
> fixed to the last commit by the server. Why wouldn't you want to use
> something fast, cheap, and highly buffered for that, even if it is
> half baked?
>
>
> Conversely,
On 25.04.2014 23:02, Les Mikesell wrote:
> On Fri, Apr 25, 2014 at 3:26 PM, Branko Čibej wrote:
>> If you absolutely must put your working copies or repositories on non-local
>> storage, you should use a SAN with a real, multi-homed distributed
>> filesystem. Anything else is half-baked, at least
On Fri, Apr 25, 2014 at 3:26 PM, Branko Čibej wrote:
>>
> If you absolutely must put your working copies or repositories on non-local
> storage, you should use a SAN with a real, multi-homed distributed
> filesystem. Anything else is half-baked, at least as far as data integrity
> is concerned.
W
On 25.04.2014 19:09, Roman Naumenko wrote:
>> That was a known consequence of moving to SQLite for storage of the
>> metadata. SVN 1.8 offers a solution for those that can use it:
>> http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking
> Mark, thank for the link. There is inde
- Original Message -
> On Fri, Apr 25, 2014 at 11:10 AM, Roman Naumenko < ro...@naumenko.ca
> > wrote:
> > - Original Message -
>
> > > On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard <
> > > markp...@gmail.com
> > > >
> > > I remember this. The deadly operation was the initial c
On Fri, Apr 25, 2014 at 11:10 AM, Roman Naumenko wrote:
>
>
> - Original Message -
> > On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard
> > wrote:
> > > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
> > >
> > > wrote:
> > >
> > >>
> > >> this topic was raised several times in the past -
- Original Message -
> On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard
> wrote:
> > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
> >
> > wrote:
> >
> >>
> >> this topic was raised several times in the past - the answers
> >> range from
> >> "will be better/solved in the next version 1
On 16 April 2014 21:13, Florian Ludwig wrote:
> Hi,
>
> this topic was raised several times in the past - the answers range from
> "will be better/solved in the next version 1.7" or "it is due to ntfs vs
> ext3/4" or it's the AV, network setup or the Windows file indexing service.
> After disablin
Grierson, David said the following, on 23-04-14, 5:47 AM:
Latency Numbers Every Programmer Should Know:
https://gist.github.com/jboner/2841832
Always useful to have in mind when considering your benchmarking environment.
Looks like svn checkouts repos on Windows strictly through Netherlands.
Johan Corveleyn said the following, on 22-04-14, 9:30 AM:
On Tue, Apr 22, 2014 at 2:55 PM, Florian Ludwig
wrote:
From your numbers I deduce that the performance degradation can be
attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
* NTFS vs. ext4: roughly a factor 3 slower.
Florian Ludwig said the following, on 16-04-14, 1:13 PM:
Hi,
this topic was raised several times in the past - the answers range
from "will be better/solved in the next version 1.7" or "it is due to
ntfs vs ext3/4" or it's the AV, network setup or the Windows file
indexing service. After dis
g
> Subject: Re: Subversion Windows Performance compared to Linux
>
> On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard wrote:
> > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
>
> > wrote:
> >
> >>
> >> this topic was raised several times in the pas
On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard wrote:
> On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
> wrote:
>
>>
>> this topic was raised several times in the past - the answers range from
>> "will be better/solved in the next version 1.7" or "it is due to ntfs vs
>> ext3/4" or it's the AV,
On Tue, Apr 22, 2014 at 10:37 AM, Florian Ludwig
wrote:
>
>
>> One thing I recall about 1.7, is that virtually none of the changes did
>> anything that really sped up checkout. So that is probably the worst thing
>> to be testing with. If all you care about is checkout, then there was
>> really
> One thing I recall about 1.7, is that virtually none of the changes did
> anything that really sped up checkout. So that is probably the worst thing
> to be testing with. If all you care about is checkout, then there was
> really little done in 1.7 or 1.8 to speed it up. Most of the big
> perf
On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig wrote:
> this topic was raised several times in the past - the answers range from
> "will be better/solved in the next version 1.7" or "it is due to ntfs vs
> ext3/4" or it's the AV, network setup or the Windows file indexing
> service. After disab
bject: Re: Subversion Windows Performance compared to Linux
From your numbers I deduce that the performance degradation can be
attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
* NTFS vs. ext4: roughly a factor 3 slower.
* Windows 7 vs. Linux: roughly a factor 2.5 slow
On Tue, Apr 22, 2014 at 2:55 PM, Florian Ludwig
wrote:
>
>>
>> From your numbers I deduce that the performance degradation can be
>> attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
>> * NTFS vs. ext4: roughly a factor 3 slower.
>> * Windows 7 vs. Linux: roughly a factor 2.5 s
> From your numbers I deduce that the performance degradation can be
> attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
> * NTFS vs. ext4: roughly a factor 3 slower.
> * Windows 7 vs. Linux: roughly a factor 2.5 slower.
>
You assume that the file operation performance of Windo
On Wed, Apr 16, 2014 at 7:13 PM, Florian Ludwig
wrote:
> Hi,
>
> this topic was raised several times in the past - the answers range from
> "will be better/solved in the next version 1.7" or "it is due to ntfs vs
> ext3/4" or it's the AV, network setup or the Windows file indexing service.
> After
Hi,
On Wed, Apr 16, 2014 at 7:33 PM, Andreas Stieger wrote:
> Can you re-run with --quiet?
>
Using --quiet did not make a difference. ( I was piping the output to
/dev/null or $null on windows so there was no output anyway. )
> Which version if SQLite is the GNU/Linux client running with?
>
Can you re-run with --quiet?
Which version if SQLite is the GNU/Linux client running with?
Regards,
Andreas
> On 16 Apr 2014, at 18:13, Florian Ludwig wrote:
>
> Hi,
>
> this topic was raised several times in the past - the answers range from
> "will be better/solved in the next version 1.7"
Hi,
this topic was raised several times in the past - the answers range from
"will be better/solved in the next version 1.7" or "it is due to ntfs vs
ext3/4" or it's the AV, network setup or the Windows file indexing
service. After disabling all those and running a test checkout on Linux
and Wind
34 matches
Mail list logo
