On 9 Apr 2010 20:59, "Greg Stein" wrote:
> Not a new API. Just a revamp of svn_io_open_unique_file3. Compare the
> 1.6.x version against trunk.
> Paul: if you're adventurous, and build your own svn, you could try
> lifting the contents of trunk's svn_io_open_unique_file3, and dropping
> that int
On Fri, Apr 9, 2010 at 3:59 PM, Greg Stein wrote:
>> Are you sure that this is in prop-base, not .svn/tmp?
>
> Whatever. Does it matter? :-P
>
> I think we should backport the changes we made in svn_io_open_unique_file3.
>
>> For 1.7 we made the tempfilename generator better in guessing new names,
On Fri, Apr 9, 2010 at 08:27, Bert Huijben wrote:
>> -Original Message-
>> From: Paul Holden [mailto:paul.hol...@gmail.com]
>...
>> 2) subversion appears to generate a temporary file in .svn\prop-base\ for
>> every file that's being updated. It's generating filenames sequentially,
>> which
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: Friday, April 09, 2010 8:27 AM
> To: 'Paul Holden'; dev@subversion.apache.org
> Subject: RE: Severe performance issues with large directories
>
> This issue is actually worse on Wind
Hi Bert,
Many thanks for the quick response.
> I think you can find a lot of issues similar to your issue in our issue
> tracker.
Searching fail on my part - sorry for re-treading old ground.
> For WC-NG we move all the entries data in a single wc.db file in a .svn
> directory below the root of
> -Original Message-
> From: Paul Holden [mailto:paul.hol...@gmail.com]
> Sent: vrijdag 9 april 2010 13:32
> To: dev@subversion.apache.org
> Subject: Severe performance issues with large directories
>
> Hello,
>
>
>
> I've had a look thro
Hello,
I’ve had a look through the issue tracker and mailing list archives and
didn’t find any references to this issue. I also assume that this is a more
appropriate mailing list than 'users'.
We’ve noticed recently that we have terrible performance when updating a
particular directory in ou
7 matches
Mail list logo
