[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "Insufficient space" error while diffing local mods

From: Jan Hendrik <jan.hendrik_at_bigfoot.com>
Date: 2004-02-26 11:41:54 CET

Concerning Re: "Insufficient space" error whil
Ben Collins-Sussman wrote on 24 Feb 2004, 10:04, at least in part:

> On Mon, 2004-02-23 at 23:28, Francois Beausoleil wrote:
> >
> > $ svn diff src\web\careernudge\contacts\contact.jsp
> [...]
> > svn: Can't write to stream: Espace insuffisant pour traiter cette
> > commande.
> > The file I am trying to diff is quite large, and I just changed most
> > of it. The diff subcommand completes fine if I redirect to a file,
> > or pipe through more.
> Hm, haven't we seen something like this before? Some bug in win32
> console i/o maybe? Brane? Sander?

I don't like to say this amidst ver. 1.0 joy and would not have
reported this at all if not Francois had come up with another,
probably distantly related problem: But since two days, just shortly
after the solution of the two missing files in one working copy, the
repos is killed by any attempt to update or commit. Just as it had
been so long and often last year. It times out (in TSVN) or just
hangs (CL) and only responds to recover then, which is quite fast
though, about 30 seconds. The server box issues a warning about
too little virtual memory after gobbling up all GB. Thus just as it had
been when SVN was in its 0.20s.

This is over Apache 2.48, file: seems to work still, but I am not
absolutely sure about this. The server is 0.34, clients had been
updated to 0.37 meanwhile, all running W2K SP2. This server had
worked without troubles since early December when I had to move
it to that box because of an HDD issue on my own where the repos
had been stable for some more weeks before. No changes in hard
or software.

At the beginning of this week there were several large commandline
commits of 500-1500 files each, all with just 2-3 characters
changed in 2 paragraphs. These commits also resulted in some
failures as either Apache timed out or the server box hibernated in
spite of the heavy network traffic to the repos (it behaves that way,
don't ask, it's a Dell). The left over transactions had been removed,
the failed commits split up and repeated succesfully. These large
commits are perhaps distantly related to Francois' large diff

As said I would not have reported this at all for it is just the old
problem here that seemed to have disappeared though it was never
obviously solved. I do not have the time this week to go into it, but
hope to give it another try with ver. 1.0 next week (if W32 binaries
are available then). However, folks here urge me to get this thing
running or remove it. And the guy sitting at the server box - small
peer2peer LAN here - and getting the slowdowns and virtual
memory warnings outright threatens to simply delete the repos if I
do not stop this error immediately. I assume to be driven out of
SVN by end of next week ... :-(

Sadly so

Jan Hendrik

Freedom quote:

     ... the question becomes,
     are you going to have everyone play by the same rules,
     or are you going to try to rectify the shortcomings,
     errors and failures of the entire cosmos?
     Because those things are wholly incompatible.
     If you're going to have people play by the same rules,
     that can be enforced with a minimum amount
     of interference with people's freedom.
     But if you're going to try to make the entire cosmos right and just,
     somebody has got to have an awful lot of power
     to impose what they think is right on an awful lot of other people.
     What we've seen, particularly in the 20th century,
     is that putting that much power in anyone's hands is enormously dangerous.
                -- Thomas Sowell, 1999

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 26 11:40:04 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.