Johan Corveleyn wrote:
[dd]
But that doesn't explain why the resulting repository is so large
(compared to the original CVS repository). Sure, there might be memory
usage problems in dump/load (it uses more memory than the resulting
repository uses diskspace), but I think there is more going
On Tue, Feb 08, 2011 at 11:32:47PM +0600, Victor Sudakov wrote:
After the 15000th commit, the size of the repository on disk is 5.5G
with the working directory size being 120M. Besides, after several
thousand commits to this directory SVN slows down considerably. This
must be some design flaw
On 2/8/2011 1:34 PM, Stefan Sperling wrote:
On Tue, Feb 08, 2011 at 11:32:47PM +0600, Victor Sudakov wrote:
After the 15000th commit, the size of the repository on disk is 5.5G
with the working directory size being 120M. Besides, after several
thousand commits to this directory SVN slows down
Les Mikesell wrote:
On Tue, Feb 08, 2011 at 11:32:47PM +0600, Victor Sudakov wrote:
After the 15000th commit, the size of the repository on disk is 5.5G
with the working directory size being 120M. Besides, after several
thousand commits to this directory SVN slows down considerably. This
Stefan Sperling wrote:
After the 15000th commit, the size of the repository on disk is 5.5G
with the working directory size being 120M. Besides, after several
thousand commits to this directory SVN slows down considerably. This
must be some design flaw (or peculiarity if you like) of SVN.
-Original Message-
From: Victor Sudakov [mailto:suda...@sibptus.tomsk.ru]
Sent: 20 January 2011 08:18
Subject: Re: Betr.: Re: svnadmin load a huge file
Colleagues,
I have finally completed a test cvs2svn conversion on an amd64 system.
The peak memory requirement of svnadmin
On Thu, Jan 20, 2011 at 9:18 AM, Victor Sudakov
suda...@sibptus.tomsk.ru wrote:
Colleagues,
I have finally completed a test cvs2svn conversion on an amd64 system.
The peak memory requirement of svnadmin during the conversion was
9796M SIZE, 1880M RES. The resulting SVN repo size is 8.5G on
That's not a nice result, but I think I said somewhere in this thread
that there are known memory-usage bugs in svnadmin dump/load. Which
means the fix (as opposed to 'workaround') to this issue is to have
someone (possibly you or someone you hire) look into those bugs.
With a bit of luck, this
On Thu, Jan 20, 2011 at 6:11 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Victor Sudakov wrote on Thu, Jan 20, 2011 at 14:18:00 +0600:
Colleagues,
I have finally completed a test cvs2svn conversion on an amd64 system.
The peak memory requirement of svnadmin during the conversion was
On 1/7/2011 7:57 AM, Victor Sudakov wrote:
It would be fine if the project in question did not contain almost all
the files in one directory. You may call the layout silly, but CVS
does
not seem to mind. OTOH, I would have distributed the files over
several subdirectories, but CVS does
10 matches
Mail list logo
