Can't seem to keep Subversion connection alive (long enough to do much)

Keep getting the following kind of fatal errors while trying to commit much at one time to the repository. It's pretty frustrating populating things for the first time (remotely) ...

Commit failed (details follow): At least one property change failed; repository is unchanged PROPPATCH of '//!svn/wrk/95867360-f61c-3947-8484-4bd35f87e635/web/som/download/som_102c.exe': Could not read status line: An existing connection was forcibly closed by the remote host.

Could be my ISP (satellite) causing trouble, but I don't have trouble with ftp.

I suppose I could try FTPing everything up to the website and doing an import from there. But just committing everything from home seemed like the simplest way to go.

That said, at this rate it's going to take maybe 100 individual commits from what I can estimate from the size of the successful commits so far.

Can't tell (after failure) that the next commit try goes any faster.

BTW: What kind of compression should I expect from the WebFaction setup? I don't see any obvious ways to configure that kind of thing via my side of the webapp. My intention is to host uncompressed (mostly binary) formats so they can be better managed differencing wise.

asked Feb 14 '11 at 14:49

Mick
1●1●8

edited Feb 14 '11 at 14:53

3 Answers:

oldest newest most voted

0	Connection is going much better tonight. No failures so far. answered Feb 16 '11 at 20:58 Mick 1●1●8

The following .htaccess rule will enable gzip

<ifModule mod_gzip.c>
  mod_gzip_on Yes
  mod_gzip_dechunk Yes
  mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
  mod_gzip_item_include handler ^cgi-script$
  mod_gzip_item_include mime ^text/.*
  mod_gzip_item_include mime ^application/x-javascript.*
  mod_gzip_item_exclude mime ^image/.*
  mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

answered Feb 14 '11 at 17:14

johns ♦♦
3454●2●7

libz (REQUIRED for client and server)

1
2
3

 Subversion uses zlib for compressing binary differences.
 These diff streams are used everywhere -- over the network,
 in the repository, and in the client's working copy.

(Feb 16 '11 at 18:47) Mick

Up higher, you had stated that "nothing is compressed in the DB" ... after looking at the different alternatives Subversion is looking a bit better. Mainly because the alternatives don't do partial checkout. Anyway, I found an old link I'd seen before but had forgotten about (http://stackoverflow.com/questions/458182/does-svn-compress-the-binary-content) which mentions another link (http://svn.apache.org/repos/asf/subversion/trunk/INSTALL) which says about libz [excerpt above] which seems to support the idea that the DB is compressed ... so just looking for a conclusive answer if possible.

(Feb 16 '11 at 18:47) Mick

I was referencing the MySQL and PostgreSQL databases, they have no compression. SVN keeps its database file as a binary, so in some sense it is 'compressed' but the exact technical details are not something I have researched. "compression" can mean any number of things and be applied at different layers of the whole, The .htaccess rule is to enable compression on HTTP traffic, not on the disk.

(Feb 16 '11 at 19:47) johns ♦♦

I use the same ISP and even under throttled conditions subversion should still work. Have you tried enabling verbosity to possibly get more information? I personally do send things to-from Webfaction by compressing them into tarballs first and have noticed it to be much faster than svn or even rsync on my WildBlue connection. However it should still work without failure. And as for compression do you mean on HTTP connections? We do not have it on by default and you would have to configure your application to do it manually, for svn I assume that would be in the .htaccess file with a series of directives. How large are the files you are moving?

answered Feb 14 '11 at 15:53

johns ♦♦
3454●2●7

Well, I've just gotten started.

I find if I go for more than like 5MBs combined file size per commit, I run a good chance of failing.

I know with WildBlue the proxied connections actually stay alive over long spans of time (like long enough for how ever many tabs to load up when restoring a browser session) but afaik, WB doesn't publish proxy configuration info for general usage (I get the impression the AT&T proxy is only intended to be used for browsing)

cont....

(Feb 14 '11 at 16:44) Mick

If I can edit the .htaccess files in my account to some affect towards Subversion, I will definitely try that. I've been operating from the assumption that is out of my reach from the webapps pov. I read some stuff in the old WebFaction forum that suggested doing your own SVN setup was probably not a good idea on their servers.

cont...

(Feb 14 '11 at 16:45) Mick

As for compression. Ideally I'd like clients to get a hint from the server to compress outgoing stuff, and I'd like the server to compress stuff before sending. And I'd definitely like to know that the stuff in the database is compressed. Because space is pretty much at a premium with WebFaction and like I said, I'd prefer to send up for example .bmp images rather than .png, so they can be better diff stored, so it's a must to know that the server is storing them compressed.

(Feb 14 '11 at 16:45) Mick

I do not use any proxies with my WildBlue connection, so could not comment on performance behind one. You may submit a support ticket and we can test it for you. You do have access to edit the .htaccess file but not the httpd.conf file. Different directives demand different levels of access. Nothing is compressed in the DB or on disk. Although disk space is one of the resources we monitor it is typically the last thing a user will over-use and databases in general are only a few MBs each if that.

(Feb 14 '11 at 17:14) johns ♦♦

Hmmm, it does look like SVN does not compress its DB. That's something I've always thought would be default because pre-compressing conflicts with the "deltafication" framework.

I think for our needs we will have to use a different CVS. I see Git in your webapps list. That may be a better first move. My account is only 10GB. My intent was for a number or related repos on the order of 100s of MBs, so not having stuff compressed could easily get out of hand. I read Git does do compression and deltas. Maybe it's time to learn something new.

I recommend testing multiMB commits for yourselves.

(Feb 15 '11 at 08:10) Mick

Your answer

If you have an answer to the above question, then use the form below. Otherwise, use the appropriate 'add new comment' button above to post your feedback.

toggle preview

community wiki

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Tags:

subversion ×14
timeout ×13
remote ×10
commit ×1

Asked: Feb 14 '11 at 14:49

Seen: 1,697 times

Last updated: Feb 16 '11 at 20:58

Can't seem to keep Subversion connection alive (long enough to do much)

Follow this question

Got questions? We have answers!

Related questions