Community site: login faq

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 14 Feb '11, 14:49

accept rate: 0%

edited 14 Feb '11, 14:53

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?

permanent link

answered 14 Feb '11, 15:53

accept rate: 23%

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)


(14 Feb '11, 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.


(14 Feb '11, 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.

(14 Feb '11, 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.

(14 Feb '11, 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.

(15 Feb '11, 08:10) Mick

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.*
permanent link

answered 14 Feb '11, 17:14

accept rate: 23%

  • libz (REQUIRED for client and server)

     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.
(16 Feb '11, 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.

(16 Feb '11, 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.

(16 Feb '11, 19:47) johns

Connection is going much better tonight. No failures so far.

permanent link

answered 16 Feb '11, 20:58

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 14 Feb '11, 14:49

question was seen: 5,658 times

last updated: 16 Feb '11, 20:58