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

clue for repos corruption?

From: Jan Hendrik <jan.hendrik_at_bigfoot.com>
Date: 2003-11-07 11:53:06 CET

Hi all out there!

It could be I found a clue for the constant repos corruption here. It
seems possible that changed timestamps without files being
actually changed causes memory not being released and furtheron
leads to the desaster:

Starting once more with the notoriously corrupted repository from
which I dumpfiltered all binary files, and two working copies, all on
my local machine, both accessing the repos through http, things
went fine for some time. Later I added GIF and JPG files step by
step. Then troubles began again.

But only with *one* working copy! The other working copy
continued operating fine, commits & updates would slightly raise
memory consumption and then fall back to the level before. But
that other working copy always raises memory usage to the ceiling
and corrupts the repos. And even after SVN has terminated with
the timeout error memory consumption goes up and up and up ...

Finally I managed to complete update on a minor directory before
the memory ceiling was reached. But then memory was *not*
released. Apache keeps every bit it has collected during update.
Only if stopped this memory is released.

Checking out a further working copy was no problem, it operates
fine, just as wc2. The three working copies are just about 2
revisions apart, perhaps 15-20 files different/new.

There is, however, one difference that may give a clue:

Some files have the timestamp changed due to uploading to the
webserver. It should be less than 50 files, but I can't say exactly.
We discussed this before. With dial up having a working copy on
the webserver is no alternative, nor is using export as it would
result in complete upload every time. Someone suggested rsynch,
however, I cannot setup an rsynch on the server and as far as I
understood clients for Windows are more or less experimental.
Anyway, having computed checksums over dial up does not sound
different from having a working copy online. The tool I currently use
compares filesize and timestamp and if at least one is different it
considers the files being different. After upload it sets the
timestamp of the local file to that on the server. That's why I get
timestamps changed in the working copy.

I won't say this could explain everything. But it seems to explain
why troubles were nearly guaranteed when the repos was on
another machine - it is always my working copy that gets
timestamps changed. There still might be an underlying memory
problem, but not with "normal" SVN operation for else corruption
should happen with the other local working copies, too.

Best regards

Jan Hendrik

Freedom quote:

     Capitalism is not an 'ism.'
     It is closer to being the opposite of an 'ism,'
     because it is simply the freedom of ordinary people
     to make whatever economic transactions they can mutually agree to.
                -- Dr. Thomas Sowell

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 7 11:49:19 2003

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.