On Sat, Jul 27, 2013 at 12:14 PM, Ben Reser wrote:
>> I am sorry to open this thread again. But it seems that this revision
>> was not included in 1.8.1. Will it be included in 1.8.2?
>
> It hasn't been nominated at this point. I haven't looked at the
> change to know if I'd be willing to nomina
I am sorry to open this thread again. But it seems that this revision
was not included in 1.8.1. Will it be included in 1.8.2?
I want to use svnsync on windows and compiling trunk on windows looks
like a nightmare after some superficial googling.
On Sat, Jul 20, 2013 at 10:31 PM, Anatoly
I confirm that the trunk do not consume more than 50Mb on this commit.
And also it is subjectively faster. You should merge this bugfix to
1.8 branch.
On Fri, Jul 19, 2013 at 2:32 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> I see those values with 1.8.x but the problem appears to be fi
>> > Does the memory usage already build up while transmitting the
>> > data (i.e. while the dots are being shown) or mainly during the
>> > commit stage, i.e. the during short delay after the last dot and
>> > the "Committed revision xyz" message?
>>
>> On transmitting data stage. During the commi
On Thu, Jul 18, 2013 at 3:24 PM, Stefan Fuhrmann
wrote:
>
>
> Have you tried it with any newer Windows version (post-W2k3)?
> There might be an address space fragmentation issue between
> CRT and OS memory management.
>
Yes. I've tried it on Ubuntu 12.08 (1.8 subversion was compiled from
download
I've just tried this at home using console apps from tortoise
distributive (1.8.0 r1490375). Computer is running Windows2003Server
32bit version.
svncync already allocated 660 Mb transmitting file data for the 5th
revision. Memory is deallocated after every new revision is
transferred, so it is no
On Wed, Jul 17, 2013 at 6:01 PM, Stefan Fuhrmann
wrote:
>
>
> All that said, it may still be necessary or at least be useful
> to retry opening any FSFS file (in case of network glitches
> etc.). Because there opening files should never fail as part
> of the normal operation, retrying when it does
iving
> an EIO error, see libsvn_fs_fs/fs_fs.c RECOVERABLE_RETRY_COUNT, but I
> don't see this being used in read_next_ids (fs_fs.c) when opening the
> next-ids file.
>
> Can anyone more knowledgeable about fsfs confirm that this is a
> possible explanation for this issue?
>
&g
8 matches
Mail list logo
