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

Re: Subversion eating up all memory (again)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-11-18 15:28:07 CET

On Nov 18, 2004, at 4:06 AM, Lukas Ruf wrote:

>> Lukas Ruf <ruf@rawip.org> [2004-11-17 18:53]:
>> currently I am committing a merge of changes with Linux 2.6.9.
>> However, Subversion is eating up all my RAM -- see next:
> This morning, after sending the other report, I tried to re-commit the
> changes in a directory-after-directory way assuming this would consume
> that much memory. There, however, I run in the following problems:
> komsys-pc-ruf:kernel!67> svn stat
> ! .
> A + kprobes.c
> M rcupdate.c
> [...]
> M kmod.c
> M futex.c
> komsys-pc-ruf:kernel!68> svn commit -m "Re-adding after time-out"
> Sending kernel/Makefile
> svn: Commit failed (details follow):
> svn: Your file or directory 'Makefile' is probably out-of-date
> svn:
> The version resource does not correspond to the resource within the
> transaction. Either the requested version resource is out of date
> (needs to be updated), or the requested version resource is newer
> than the transaction root
> (restart the commit).

Lukas: the problem is that your commit *succeeded* in the server, but
your client timed out waiting for the server to send back a detailed
description of the files that changed. I saw that message in your
previous mail.

So now your working copy still has local edits, but if you try to
commit, they're all "out of date" (since the changes are already in the
server), and if you try to update your working copy, every file will
receive a conflicting change.

So you need to 'svn revert -R .' your working copy, 'svn update', and
all will be fine again.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 18 15:28:46 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.