On Wed, Jul 17, 2013 at 7:28 AM, Ben Reser wrote:
> The 1.8.1 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on July
> 23rd so please try and g
On Wed, Jul 17, 2013 at 7:27 AM, Ben Reser wrote:
> The 1.7.11 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on July
> 23rd so please try and
I see those values with 1.8.x but the problem appears to be fixed on
trunk where the memory use is remains more or less constant at 100MB
virtual, 25MB resident.
Philip Martin writes:
> I see smaller numbers on my 64-bit Linux box. r18 is the worst at about
> 550MB.
>
> Anatoly Zapadinsky write
I see smaller numbers on my 64-bit Linux box. r18 is the worst at about
550MB.
Anatoly Zapadinsky writes:
> 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 t
On Thu, Jul 18, 2013 at 4:08 PM, Anatoly Zapadinsky wrote:
> >> > 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 revis
>> > 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:10 PM, Anatoly Zapadinsky wrote:
> 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.
>
> Ye
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
On Thu, Jul 18, 2013 at 11:26 AM, Anatoly Zapadinsky
wrote:
> I've just tried this at home using console apps from tortoise
> distributive (1.8.0 r1490375). Computer is running Windows2003Server
> 32bit version.
>
I can't reproduce this on LINUX. I will run this later today on
Win7 32 bits.
Have
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
Ok, problem with the monitoring.
The peak for the first 1600 revisions was about 586 MB.
Bert
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: donderdag 18 juli 2013 09:23
To: 'Anatoly Zapadinsky'; 'Lieven Govaerts'
Cc: 'Subversion Development'
Subject: RE: svnsync cras
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
Hi,
I just tried svnsyncing the chromium repository to my local machine
(Subversion 1.8.0, standard SlikSvn binary) on Windows and the svnsync
process didn't get above 86 MB memory usage syncing the first 563 revisions.
This was a sync to a local harddisk.
The number of open han
13 matches
Mail list logo
