Re: Checkout fails on large repository
I would like to add some software specs for client and server: Server: OS: Debian GNU/Linux, squeeze Subversion: 1.6.12dfsg-6 Apache: 2.2.16-6+squeeze Client: OS: Ubuntu 11.04 Subversion: 1.6.12dfsg-4ubuntu2.1 Furhter info: There is only one user accessing the repository during checkout. So issues caused by multiple users accessing it can be eliminated. It seems to be the same place it fails every time. That is, the same path. I am currently trying to checkout this path alone in a tmp dir to see if it works. The checkout takes some some time though so I will post the result later. If you already have some ideas as to what is wrong, I will appreciate your suggestions. Thanks. Med venlig hilsen/Kind regards Thomas
Re: Checkout fails on large repository
> Hello > > I have a fairly large repository (~75 GB) containing mostly binary > files (photos). > When I try to do a checkout, it fails after checking out about 7.5 GB. > > On the client, this error is shown: > svn: REPORT of '/svn/photo/!svn/vcc/default': Could not read response > body: Secure connection truncated (https://svn) > svn co https://svn/svn/photo tdn-photos 1635,48s user 289,84s system > 8% cpu 6:03:45,40 total > > On the server, this error is written in the log: > ==> /data/www/virtual/svn/log/error.log <== > [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Provider > encountered an error while streaming a REPORT response. [500, #0] > [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] A failure > occurred while driving the update report editor [500, #103] > [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Error writing > base64 data: Software caused connection abort [500, #103] > > ==> /data/www/virtual/svn/log/access.log <== > 10.0.0.4 - tdn [11/Aug/2011:18:38:35 +0200] "REPORT > /svn/photo/!svn/vcc/default HTTP/1.1" 200 4094599482 "-" "SVN/1.6.12 > (r955767) neon/0.29.5" > > > I have tried turning off SSL and thus using regular HTTP instead of HTTPS. > This did not fix the problem. I receive the same error. > > I hope you can help me fix this problem. Hi Thomas, I've run into similar problems where the total commit size was large and the network speed to the server was slow (or blocked up). If the network link is not cleared fast enough this seems to cause things to timeout in the webdav layer. In our case it was actually write speed to NFS drives at the client end on our build farm that was slowing the whole process and backing up the network connection. The simplest workaround we found was to restart the update as the client detects the failure and appears to clean up the working copy so that a restart is possible. The following links describe what we ran into but we never really got a better solution rather than the above one I'm afraid: - http://sourceforge.net/apps/trac/sourceforge/ticket/1576 - http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/<009501cac5d0$0e661140$2b3233c0$@qqmail.nl> Hope this helps. Simon
connection aborted error (730053) during checkout with 1.7.0-beta-3
Hi, I tried to checkout a subversion repository with the latest beta today. While there are no problems using 1.6, the checkout with 1.7 always fails with a connection aborted error after a number of files: "svn: E730053: Error retrieving REPORT (730053): Eine bestehende Verbindung wurde softwaregesteuert durch den Hostcomputer abgebrochen." The protocol is https. client: pre-release binary 1.7.0-beta3-win32 from CollabNet (I'm using Windows XP Pro SP3, 32-Bit) server: 1.6.16 A similar issue was reported here: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2803578 Regards Dennis
Re: Checkout fails on large repository
2011/8/16 Thomas : > There is only one user accessing the repository during checkout. So > issues caused by multiple users accessing it can be eliminated. > It seems to be the same place it fails every time. That is, the same path. > I am currently trying to checkout this path alone in a tmp dir to see > if it works. The checkout takes some some time though so I will post > the result later. I just checked. The checkout of this path went fine. Total size of the WC of this path is 575 MB. Med venlig hilsen/Kind regards Thomas
Re: connection aborted error (730053) during checkout with 1.7.0-beta-3
On Tue, Aug 16, 2011 at 09:47:30AM +0200, Dennis Kieselhorst wrote: > Hi, > > I tried to checkout a subversion repository with the latest beta > today. While there are no problems using 1.6, the checkout with 1.7 > always fails with a connection aborted error after a number of > files: > "svn: E730053: Error retrieving REPORT (730053): Eine bestehende > Verbindung wurde softwaregesteuert durch den Hostcomputer > abgebrochen." > The protocol is https. Does setting 'http-library=neon' at the very end of the file ~/.subversion/servers fix the problem?
Re: Checkout fails on large repository
On Tue, Aug 16, 2011 at 09:53:05AM +0200, Thomas wrote: > 2011/8/16 Thomas : > > There is only one user accessing the repository during checkout. So > > issues caused by multiple users accessing it can be eliminated. > > It seems to be the same place it fails every time. That is, the same path. > > I am currently trying to checkout this path alone in a tmp dir to see > > if it works. The checkout takes some some time though so I will post > > the result later. > > I just checked. The checkout of this path went fine. Total size of the > WC of this path is 575 MB. Does your Apache HTTPD Server use keep-alive? http://httpd.apache.org/docs/2.0/mod/core.html#keepalive Try to increase the KeepAliveTimeout option in your Apache configuration: http://httpd.apache.org/docs/2.0/mod/core.html#keepalivetimeout The default is 15 seconds. For large checkouts, the svn client could be busy for longer than 15 seconds before it sends another request.
Re: Checkout fails on large repository
2011/8/16 Stefan Sperling : > Does your Apache HTTPD Server use keep-alive? > http://httpd.apache.org/docs/2.0/mod/core.html#keepalive > > Try to increase the KeepAliveTimeout option in your Apache > configuration: > http://httpd.apache.org/docs/2.0/mod/core.html#keepalivetimeout > > The default is 15 seconds. For large checkouts, the svn client could > be busy for longer than 15 seconds before it sends another request. I have now enabled KeepAlive and set Timeout and KeepAliveTimeout to 900. We'll see how it goes.
Re: Checkout fails on large repository
Stefan Sperling wrote on Tue, Aug 16, 2011 at 11:24:06 +0200: > On Tue, Aug 16, 2011 at 09:53:05AM +0200, Thomas wrote: > > 2011/8/16 Thomas : > > > There is only one user accessing the repository during checkout. So > > > issues caused by multiple users accessing it can be eliminated. > > > It seems to be the same place it fails every time. That is, the same path. > > > I am currently trying to checkout this path alone in a tmp dir to see > > > if it works. The checkout takes some some time though so I will post > > > the result later. > > > > I just checked. The checkout of this path went fine. Total size of the > > WC of this path is 575 MB. > > Does your Apache HTTPD Server use keep-alive? > http://httpd.apache.org/docs/2.0/mod/core.html#keepalive > > Try to increase the KeepAliveTimeout option in your Apache > configuration: > http://httpd.apache.org/docs/2.0/mod/core.html#keepalivetimeout Please don't link to the 1.0 book, use http://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout http://httpd.apache.org/docs/current/mod/core.html#keepalivetimeout instead :-)
[no subject]
Restored 'military/jquery.advancedSlider.min.js' Restored 'military/style.css' Restored 'military/index_old.php' Restored 'military/jquery.advancedSlider.js' Restored 'military/advanced-slider.css' Restored 'military/jquery-1.4.3.min.js' Restored 'military/excanvas.compiled.js' Restored 'military/index1.php' ? stec ? products ? css/milstyle.css M css/advanced-slider.css M military/embeddedssd.php M military/index.php M military/ruggedssd.php M v2nav/headers/v3_military_header.php ? STEC/v2swf ? STEC/Scripts ? STEC/css ? STEC/ssd ? STEC/error404.php.k ? STEC/script A STEC/webspeed/images/prod_images M STEC/product/mach16.php M STEC/product/mach8.php M STEC/product/kronos.php M STEC/interface/sata.php ? images/military/slider-assets You have mail in /var/spool/mail/webuser [webuser@dev102:/sites/www/military] svn commit -m="" * Adding archive Adding archive/index1.php Adding archive/index_old.php Sendingembeddedssd.php Sendingindex.php Sendingperformancessd.php Sendingruggedssd.php Transmitting file data .. Committed revision 9280. Warning: post-commit FS processing had error 'Can't remove '/users/repos/db/transactions/9279-1.txn/ ''. [webuser@dev102:/sites/www/military] svn list _notes/ advanced-slider.css css/ embeddedssd.php excanvas.compiled.js images/ index.php index1.php index_old.php jquery-1.4.3.min.js jquery.advancedSlider.js jquery.advancedSlider.min.js js/ performancessd.php ruggedssd.php slider-assets/ slider.xml style.css v2nav/ [webuser@dev102:/sites/www/military] ll total 96 drwxr-xr-x 3 webuser webuser 4096 Aug 15 12:37 archive -rwxr-xr-x 1 webuser webuser 25161 Aug 15 10:53 embeddedssd.php -rwxr-xr-x 1 webuser webuser 9846 Aug 15 10:43 index.php drwxrwxr-x 3 webuser webuser 4096 Aug 15 12:00 _notes -rwxr-xr-x 1 webuser webuser 17340 Aug 15 11:03 performancessd.php -rwxr-xr-x 1 webuser webuser 20935 Aug 15 10:59 ruggedssd.php -rw-r--r-- 1 webuser webuser 2483 Apr 26 10:28 slider.xml Thank you Michael, for your response. This server have been in production for a long time and there is no plan to upgrade it. However openssl is installed on it, OpenSSL 0.9.7f 22 Mar 2005 -Original Message- From: Michael Diers [mailto:mdi...@elegosoft.com] Sent: Monday, August 15, 2011 7:59 AM To: Kathy Khaghani Cc: 'users@subversion.apache.org' Subject: Re: Transmitting file data .svn: Commit failed On 2011-08-10 19:48, Kathy Khaghani wrote: > Hello again, > > In hopes of fixing an error on apache server crashing every time a commit is > done, I upgraded my svn to: > svnadmin, version 1.6.17 (r1128011) > > My openssl version is: > OpenSSL 0.9.7f 22 Mar 2005 > > And apache server: > Server version: Apache/2.0.54 > > So I downloaded the source for subversion and subversion-deps and compiled > them: > > ./configure --with-ssl --with-libs=/usr/lib > --prefix=/usr/local/src/subversion-1.6.17 > make > make install > > > and now I get this error when I commit or svn list: > svn: SSL is not supported > > > any suggestion is highly appreciated. > > Best regards, > Kathy [...] Are you really running Fedora Core 4 on your server? It was released in 2005, and has been unsupported by the Fedora Project since 2007 or so. That means it has not seen any security updates in yonks... The SSL library is not part of the subversion-deps tarball. You'll most likely need to install the SSL development kit packages from the Fedora package repository (openssl or gnutls). Or build those from source as well, as there probably won't be any current releases packaged for FC4. -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED This electronic transmission, and any documents attached hereto, may contain confidential, proprietary and/or legally privileged information. The information is intended only for use by the recipient named above. If you received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited, and violators will be pursued legally.
Re: Delay syncing to mirror repositories causing issues
On 15/08/2011, at 23:30 , Nico Kadel-Garcia nkadel-at-gmail.com |subversion users list| wrote: > This is *precisely* the situation I warned about last week? When > someone else was trying to set up that kind of live mirror pretending > to be a master-master setup. I'm quite 3.5 hours is impressive, > though. How did that happen, if you don't mind giving more detail. Essentially we run one master and use hook scripts to sync out to the remote slave servers. In this instance there was a ~700Mb binary blob checked in to the master. The 3.5 hour delay was predominately transfer time of the 700Mb transaction set across our loaded inter-office link.
Re: Delay syncing to mirror repositories causing issues
On 15/08/2011, at 22:54 , Stefan Sperling stsp-at-elego.de |subversion users list| wrote: > On Mon, Aug 15, 2011 at 01:34:15AM +, Simon wrote: >> We have a main master repository and a number of mirror slave >> repositories at a bunch of locations that are set up as webdav >> transparent write-through proxies. These are synced by a process >> similar to svnsync, and this all seems to work okay. > > So you're using a different synchronisation process than svnsync? > How does it work? What prevents you from using svnsync? What's the > commit-transfer latency of your procedure compared to the latency of svnsync? Our sync mechanism essentially uses svnadmin dump at the master and svnadmin load at the slaves with some home cooked supervisory functionality to gel it all together. This may not be optimal but my understanding is that our sync mechanism was developed to work around some prior problems in svnsync for large commits. It is possible that the original svnsync problem has long since been fixed but the infrastructure is now somewhat standardised and I have very limited control over the infrastructure that I have available. >> However, it is inevitable that there is delay in the commits at the >> master repository propagating out to the slaves. This is not usually a >> problem, except when a large commit has been made where the transfer >> time of the revisions data is significant. In this situation the a >> client that uses the slave repository can have its commit blocked >> because it is unable to update to the latest revision because the >> slave repository is out of sync. This is unfortunate because it makes >> the slave repository somewhat useless until the sync has time to >> resolve itself. In a recent situation our slave was out of sync for >> around 3.5 hours. >> >> Is there a workaround for this situation? > > You're not telling why one or more commits took 3.5 hours to sync. > Why was the date set larger than usual? Maybe if you provide more > information about this someone will come up with a workaround. This was a 700Mb checkin synced out to slaves over a loaded WAN link, so this was predominately transfer time of the data blob for the commit. > One scenario where a large commit can happen is when a lot of new > revisions are imported from a dumpfile, e.g. when a project is moved > from one repository to another. > The Apache Software Foundation (ASF) uses a write-through proxy setup. > The main server is in the US and the mirror is in Europe. Occasionally, > new code is imported with history when a project joins the ASF. > The new revisions are stored in a dump file which is copied to the master > and the slave. Next, commit access is temporarily disabled on both servers. > The dump file is loaded into both repositories. svnsync meta data is updated > on the slave to mark the current head revision as synced (this number > is in the svn:sync-last-merged-rev revision property at revision 0). > Now when commit access is re-enabled the master and slave are already > in sync. The resulting downtime is lower than if the newly imported > revisions were imported at the master and synced via svnsync.
Re: Delay syncing to mirror repositories causing issues
On 16/08/2011, at 02:34 , Stefan Sperling stsp-at-elego.de |subversion users list| wrote: > On Mon, Aug 15, 2011 at 11:06:29AM -0500, Les Mikesell wrote: >> I suppose the direct access could help in the case where the >> revision taking too long to sync is not the same data the client >> needs for its update, but otherwise it could make things worse. > > Good point. > > I was thinking of operations like 'svn log', 'svn diff' etc. > An update will need to pull the same data the sync is getting, of course. Direct access would certainly help in the case where the revision in transit was unrelated to a clients working copy. In fact I would probably expect this to be the usual case. Even though deferring to the master in this case (where the transaction is related to the working copy), could make things worse in terms of absolute sync time, the current situation is that the slave can't be used for some operations during this period. In our situation fully coherent access to what the master server sees is a higher priority than update time, but I understand that others may have a different priority here.
Re: Delay syncing to mirror repositories causing issues
On Tue, Aug 16, 2011 at 09:31:21AM +1000, Simon Takita wrote: > > On 16/08/2011, at 02:34 , Stefan Sperling stsp-at-elego.de |subversion users > list| wrote: > > > On Mon, Aug 15, 2011 at 11:06:29AM -0500, Les Mikesell wrote: > >> I suppose the direct access could help in the case where the > >> revision taking too long to sync is not the same data the client > >> needs for its update, but otherwise it could make things worse. > > > > Good point. > > > > I was thinking of operations like 'svn log', 'svn diff' etc. > > An update will need to pull the same data the sync is getting, of course. > > > Direct access would certainly help in the case where the revision in transit > was unrelated to a clients working copy. In fact I would probably expect this > to be the usual case. > > Even though deferring to the master in this case (where the transaction is > related to the working copy), could make things worse in terms of absolute > sync time, the current situation is that the slave can't be used for some > operations during this period. In our situation fully coherent access to what > the master server sees is a higher priority than update time, but I > understand that others may have a different priority here. > Right. I think the slave should be selective about what it forwards to the master. E.g. requests for log messages can certainly be sent to the master without causing much harm. The only real problem would be an update to a revision that is currently syncing or about to be synced. A diff/blame operation that involves this revision might also cause undesired traffic. We should try to improve the error message users get to see. If mod_dav_svn were to peek at the svn:sync-* properties to determine whether a sync is happening, it could annotate error messages for failed read requests with a "please try again later" message. (Yes, this assumes svnsync is being used -- dump/load isn't really the standard way of doing this, sorry).
Re: Delay syncing to mirror repositories causing issues
Stefan Sperling wrote on Tue, Aug 16, 2011 at 15:58:13 +0200: > Right. I think the slave should be selective about what it forwards to > the master. E.g. requests for log messages can certainly be sent to the > master without causing much harm. The only real problem would be an update > to a revision that is currently syncing or about to be synced. > A diff/blame operation that involves this revision might also cause > undesired traffic. > For that matter you could try and cache those revprops somewhere, even though the FS' youngest revision is older than them. I'd probably prefer to see them separated from the FS revprops proper --- ie, from the revprops that correspond to existing revisions --- in order to maintain sanity of the FS code maintainers. > We should try to improve the error message users get to see. If mod_dav_svn > were to peek at the svn:sync-* properties to determine whether a sync is > happening, it could annotate error messages for failed read requests with > a "please try again later" message. (Yes, this assumes svnsync is being > used -- dump/load isn't really the standard way of doing this, sorry). Agreed; the proxy could could check for svn:sync-lock, svn:rdump-lock, and maybe svn:I-am-syncing-the-proxy-via-some-other-means, revprops on r0. And it could include the URL of the master in the error message... though, strictly speaking, I'm not sure that we expose that URL to clients today? (so we may want to make this disclosure of information optional)
JavaHL bindings - post-commit error messages
Hello, is there a way to receive get post-commit error messages on performing a commit with the JavaHL bindings? According to the SVN book: "If the post-commit hook returns a nonzero exit status, [...] anything that the hook printed to stderr will be marshalled back to the client, making it easier to diagnose hook failures." Best regards, Martin
Re: JavaHL bindings - post-commit error messages
On Tue, Aug 16, 2011 at 11:09 AM, Martin Kutter wrote: > > is there a way to receive get post-commit error messages on performing a > commit with the JavaHL bindings? > > According to the SVN book: "If the post-commit hook returns a nonzero exit > status, [...] anything that the hook printed to stderr will be marshalled > back to the client, making it easier to diagnose hook failures." > Subclipse uses JavaHL and I believe it shows these messages. Have you registered a call back to receive the Notifications? http://subversion.apache.org/docs/javahl/1.6/org/tigris/subversion/javahl/Notify2.html -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Transmitting file data .svn: Commit failed
On Mon, Aug 15, 2011 at 10:59 AM, Michael Diers wrote: > On 2011-08-10 19:48, Kathy Khaghani wrote: >> Hello again, >> >> In hopes of fixing an error on apache server crashing every time a commit is >> done, I upgraded my svn to: >> svnadmin, version 1.6.17 (r1128011) >> >> My openssl version is: >> OpenSSL 0.9.7f 22 Mar 2005 >> >> And apache server: >> Server version: Apache/2.0.54 >> >> So I downloaded the source for subversion and subversion-deps and compiled >> them: >> >> ./configure --with-ssl --with-libs=/usr/lib >> --prefix=/usr/local/src/subversion-1.6.17 >> make >> make install >> >> >> and now I get this error when I commit or svn list: >> svn: SSL is not supported >> >> >> any suggestion is highly appreciated. >> >> Best regards, >> Kathy > [...] > > Are you really running Fedora Core 4 on your server? It was released in > 2005, and has been unsupported by the Fedora Project since 2007 or so. > That means it has not seen any security updates in yonks... > > The SSL library is not part of the subversion-deps tarball. You'll most > likely need to install the SSL development kit packages from the Fedora > package repository (openssl or gnutls). Or build those from source as > well, as there probably won't be any current releases packaged for FC4. Or simply update your Fedoar. Seriously, you're going to run into problems like this more and more as you try to use contemporary versions of open source components. It's not fair, to the developers of those products, to rely on compatibility with obsolete operating systems.
Re: sporadic, hanging connections to apache svn (centos 5.4)
On Mon, Aug 15, 2011 at 11:08 PM, Seth Daniel wrote: > Hi, > > I've done many subversion installs but never have I seen the following > problem before. > > Vanilla Centos 5.4. Subversion 1.6.17 (compiled and packaged by me). > Nothing fancy with the compilation. I use an 'amalgamated' sqlite > 3.6.23 when configuring...otherwise no other options to configure. Then > make; make install. The client being used is from the same 1.6.17 > package. Apache with prefork MPM (centos 5.4 comes with apache 2.2.3). Dude!!! I'm building up an SRPM for RPMforge, backported from the Fedora Core 16 test release of subversion-1.6.17. Would you care to share notes,, or perhaps even test mine as scratch monkey (http://www.catb.org/jargon/html/S/scratch-monkey.html) ? I also encourage you to jump to CentOS 5.6: while it took a while to come out, there are numerous small improvements that pay off at tough moments, like the profound stability updates to autofs. > The problem: Occasional and (so far) non-deterministic 'hangs'[1] of > subversion requests. It doesn't seem to matter if it's a commit or a > status or a log. Eventually, at some point, a request to the server > will hang. All requests are https. That's no good!!! > If I perform an strace on the client and an strace on the Apache child > servicing the client they are both 'poll'ing. I don't see any errors or > warnings in the various apache logs. > > During the time this one request 'hangs' other requests are serviced > just fine by the other apache children. > > I have read that apr sometimes needs to be compiled to use /dev/urandom. > I am using the apr libs that come with Centos 5.4. This is apparently > apr 1.2.7. Can an apr that uses /dev/random cause the problem I am > describing? I can find no evidence that the apr that comes with Centos > 5.4 is compiled to use /dev/urandom, but I'm likely missing something > obvious (I installed the apr-devel package and ran through the options > for apr-1-config, such as --cppflags, and none mentioned a switch for > compiling with /dev/urandom). I really encourage you do update to CentOS 5.6 to help with underlying architectural problems that may have been addressed two years ago by the upstream vendor. I also assume that you're using the HTTPS based access: can you test with svn:// or ssh+svn:// > If someone has any other ideas for figuring out what is going on I'm all > ears and can do (most) any task. One thing I have not been able to do > is get it to consistently hang. I have to run a request in a loop and > eventually a request will hang. Sometimes it takes 10 minutes, > sometimes 1-2 hours...but eventually one of the requests will hang. > > Thanks folks. > > > [1] it does not hang forever. it simply takes a very long time to > respond. I've seen as long as 45 minutes for a very simple log request > that just seconds earlier took about 1-2 seconds to return. That.. is not good. I wonder if you do have an "I ran out of randomness" issue? Can you roll back to the subversion-1.6.11 from CentOs 5.6, or the subversion-1.6.15 from RPMforge (that I helped bundle) on another server, and see if you can replicate the behavior? Is this a wildly *busy* server?
Re:
On 2011-08-15 23:02, Kathy Khaghani wrote: [...] > Thank you Michael, for your response. This server have been in > production for a long time and there is no plan to upgrade it. > However openssl is installed on it, OpenSSL 0.9.7f 22 Mar 2005> [...] Kathy, please check config.log in the neon build directory. It should tell you if OpenSSL was properly detected. Here's a sample from a neon config.log (not from a build on FC4, though): [...] configure:27262: checking for pkg-config configure:27280: found /usr/bin/pkg-config configure:27293: result: /usr/bin/pkg-config configure:27637: checking for openssl pkg-config data configure:27648: result: yes configure:27655: using SSL library configuration from pkg-config configure:28013: checking openssl/ssl.h usability configure:28030: gcc -c -g -O2 -D_LARGEFILE64_SOURCE -DNE_LFS conftest.c >&5 configure:28036: $? = 0 configure:28050: result: yes configure:28054: checking openssl/ssl.h presence configure:28069: gcc -E -D_LARGEFILE64_SOURCE -DNE_LFS conftest.c configure:28075: $? = 0 configure:28089: result: yes configure:28122: checking for openssl/ssl.h configure:28130: result: yes configure:28013: checking openssl/opensslv.h usability configure:28030: gcc -c -g -O2 -D_LARGEFILE64_SOURCE -DNE_LFS conftest.c >&5 configure:28036: $? = 0 configure:28050: result: yes configure:28054: checking openssl/opensslv.h presence configure:28069: gcc -E -D_LARGEFILE64_SOURCE -DNE_LFS conftest.c configure:28075: $? = 0 configure:28089: result: yes configure:28122: checking for openssl/opensslv.h configure:28130: result: yes configure:28150: checking OpenSSL version is >= 0.9.7 configure:28176: result: yes configure:28179: OpenSSL >= 0.9.7; EGD support not needed in neon configure:28190: SSL support enabled, using OpenSSL (0.9.7 or later) [...] -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de
AW: connection aborted error (730053) during checkout with 1.7.0-beta-3
Hi Stefan! >> I tried to checkout a subversion repository with the latest beta >> today. While there are no problems using 1.6, the checkout with 1.7 >> always fails with a connection aborted error after a number of >> files: >> "svn: E730053: Error retrieving REPORT (730053): Eine bestehende >> Verbindung wurde softwaregesteuert durch den Hostcomputer >> abgebrochen." >> The protocol is https. > Does setting 'http-library=neon' at the very end of the file > ~/.subversion/servers fix the problem? Thanks, the setting fixed it. After digging further into it I assume that the serf library is causing the connection abort problems. I advised our administrators to have a look at the hints given in the relating section of the release notes: http://subversion.apache.org/docs/release-notes/1.7.html#serf Regards Dennis
Need to chaeck mime-type on a specific extension
Hi, I need to reject commits that have a file extension .mdl and don't have svn:mime-type set to application/octet-stream. Does anyone have a pre-commit hook that will do this or similar? Thanks. Michael.
Re: Detecting where the commit has been send from
On 2011-08-13, Ryan Schmidt wrote: > > On Aug 11, 2011, at 15:50, wimpunk wrote: > >> I'm wondering if there is a way to detect where the commit has been >> send from while doing a postcommit. Is there a way to do this? > > What do you mean by "where"? You should be able to figure out the username of > the person who committed the change. If you want more info like their IP > address then that is not available. > I was trying to find the IP address... so it looks doesn't work by default. > My svnhookdispatcher adds extra hooks to Subversion by parsing the > mod_dav_svn log; you might be able to hack it to parse out the IP address and > send that to a modified post-commit hook, assuming you are serving your > repository with apache. > > http://ryandesign.com/svnhookdispatcher/ > > It's been years since I wrote svnhookdispatcher; since then, svnserve has > gained a log too. Not sure if IP addresses are logged there. > I'll take a look, maybe I can modify it to get the IP address... > >
Re: Need to chaeck mime-type on a specific extension
> Hi, I need to reject commits that have a file extension .mdl and don't have > svn:mime-type set to application/octet-stream. > > Does anyone have a pre-commit hook that will do this or similar? I just happen to have such a hook. The hook is in Perl, but doesn't require anything that doesn't come installed with Perl 5.8 or later (unless you want to use LDAP groups). All you need is a control.ini file with this entry to do what you want: [property ALL MDL files need the property "svn:mime-type" on them] file = **/*.mdl property = svn:mime-type type = string value = application/octet-stream Try this version first: http://dl.dropbox.com/u/433257/newest_svn_hooks.zip. This is a compete rewrite and is much easier to understand and maintain. However, it might still have a few bugs in it since it hasn't been widely distributed. I have an older version here: http://dl.dropbox.com/u/433257/new_svn_hooks.zip. It's been more battle tested, but has fewer features and the error messages are not as clear. I wanted to add some user requested features, but realized the code was pretty awful and rewrote it from scratch. In this version, you can't use the "file" parameter. You use the "match" parameter and provide it with a Perl regular expression like this: [property ALL MDL files need the property "svn:mime-type" on them] match = \.mdl$ property = svn:mime-type type = string value = application/octet-stream Let me know how it works for you. -- David Weintraub qazw...@gmail.com
Re: Subversion and SalesForce integration
My appology if this question does not quite belong here but I'll try. You could have tried asking here http://success.salesforce.com/ We use SalesForce as our bug tracking system. Does anybody knows how SVN can be integrated with SalesForce so it can track commits a-la Jira? In Jira you can attach SVN commits to a ticket. We want to attach SVN commit history to the SalesForce case. A little googling resulted in the following link. Not sure if it helps. http://blog.deadlypenguin.com/blog/2009/04/29/salesforcecom-and-subversion/ -- Regards, Jeyanthan
