Re: SSL handshake failed: SSL error: A TLS warning alert has been received.
The same problem has just manifested when using ubuntu lucid either due to a package update or possibly changes on the server side. I now get the following error when attempting an svn update (svn info works fine). SSL handshake failed: SSL error: A TLS warning alert has been received. I tried using the LD_PRELOAD=/usr/lib/libneon.so.27 before the command but this resulted in the error message: SSL handshake failed: SSL error code -1/1/336032856 The difference between these being that the first is using a version of libneon build against gnutls whereas the second uses openssl. It seems the error in the first case is down to a problem with libneon which according to the changelog has been fixed in version 0.29-5 (0.29-1 is the current version for lucid). By building my own libneon (using -with-ssl=gnutls to specift gnutls rather than openssl) and subversion has worked. Guess libneon package should be updated to version >= 0.29-5. Nico Kadel-Garcia-2 wrote: > > On Mon, Sep 6, 2010 at 5:40 AM, Bert Huijben wrote: >> >> >>> -Original Message- >>> From: Gero [mailto:g...@ieee.org] >>> Sent: maandag 6 september 2010 11:37 >>> To: users@subversion.apache.org >>> Subject: Re: SSL handshake failed: SSL error: A TLS warning alert has >>> been >>> received. >>> >>> On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote: >>> On Wed, Aug 11, 2010 at 10:24 AM, Gero wrote: >>> > > Hi, >>> > > >>> > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no >>> longer access >>> > > an SVN repository: >>> > > >>> > > $ svn update >>> > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL >>> handshake >>> > > failed: SSL error: A TLS warning alert has been received. >>> > > (https://example.com) >>> > >>> > But 'svn info 'https://example.com/path/to/svn/trunk works? What >>> about >>> > doing a clean checkout to a new location? >>> >>> 'svn info' with no arguments works and shows info about the repository >>> in question. 'svn info ', however, does not work, with the same >>> error message as above. A clean checkout doesn't work either. >>> >>> There is an Ubuntu bug report about Subversion not playing with the >>> latest libneon nor libneon-gnutls. Apparently, libneon now reports more >>> SSL problems that Subversion should ignore, but doesn't. >> >> Subversion uses neon and neon uses your SSL library. Subversion doesn't >> use >> the ssl library directly. >> >> So this should be fixed either in Neon or (to restore compatibility with >> the >> older version) in the SSL library. >> >> Bert > > Really? Why do you think this? > > For RHEL 5, the RPMforge packages actually have to include > compatibility versions of python, neon, and swig. Component drift for > the 4 major and several variant methods of accessing a Subversion > repository is a demonstrable issue: between local file access, > svnserve, HTTP, and the minor variants of HTTPS and ssh+svn, you have > a potential for a lot of subtle version skew in components themselves > and especially in the interfaces to those components. > > It's already awkward with enterprise operating systems, which are very > reluctant to upgrade system components. (See the RHEL 5 comment, and I > went through this with SCO OpenServer 5 myself.) It seems > unsurprising that Ubuntu, that tends to be leading edge, is > encountering version skew issues from the other side. > > -- View this message in context: http://old.nabble.com/SSL-handshake-failed%3A-SSL-error%3A-A-TLS-warning-alert-has-been-received.-tp29409554p32249793.html Sent from the Subversion Users mailing list archive at Nabble.com.
RE: Parallel branches/tags/trunk directories
> On Aug 11, 2011, at 12:21, Andy Levy wrote: > > > I'm trying to find the documentation (release notes, CHANGES file) to > > corroborate Bob's description of how Sparse Directories work with > > pre-1.6 servers, but I can't. I have the same recollection he does - > > that you're still downloading everything and just discarding the items > > that don't match the depth you've set. I see the same behavior with my > > 1.5.2 server and 1.6 clients. > > http://subversion.apache.org/docs/release-notes/1.5.html#sc-compat > Thanks for that. I was close. It is actually pre 1.5 servers that will still send all the data. And the OP is running 1.4... perhaps if he upgrades to 1.6 and the perf is improved he won't struggle as much with sparse directories. BOb
RE: Subversion on Drupal
> My goal in learning Subversion was to put our web site under version control. > Now I have my doubts as to whether Subversion can handle it. > > The web site uses Drupal. And Drupal has the characteristic that much of the > site is contained in a MySQL database. For example, if I install a module and > set it up, the module is a disk file, but the configuration of that module is > in > the database. If I make a change, part of the change may be in a PHP code > file on disk, part may be in the database. > The database contains both user data and configuration data, intermingled. > > I could get Subversion to work. I would have a pre-commit script to back up > the database to a disk file in the working copy. I would have a post-checkout > script to reload the database from the disk file. Along with svn commit and > svn checkout, this would give us the ability to roll back to any earlier > version. > > What I can not imagine is how to get more than one person to be able to > work on the site. Yes, Subversion would be able to merge changes to the disk > files. But I don't see how Subversion can handle merging changes to the > database. The MySQL database is text; perhaps someone here as experience > with that. Can MySQL backup files be merged? Versioning database schema changes and data changes is a challenge but not impossible. BTW: svn does control binaries but not as well as text files. There are tools to do db migrations where the migrations are scripts that modify your database. You source control the migration scripts and then your build/deploy process can run these migration scripts. Basically, it inspects the current "version" of the database and runs the appropriate scripts. If you really want to get fancy your scripts can migrate UP or DOWN version too... but usually not necessary to go down version in production. You can also dump your database and put that in source control for dev. This way you can recover to any "version" but just loading up that dump. We use a tool called DBGhost. It is for SQL Server only but it has a sync engine that will build the database from the source scripts and then compare that to the current live database and make the needed changes. It supports schema and data changes. It also allows you to control data changes by columns, so for example you can have a column in a table that specifies if the rows are "shipped" rows or customer rows and have it not touch the customer data. Be creative and I'm sure you can come up with a way to revision your database changes. If you google "source control database" you will find lots of ideas and hints. BOb
Re: svnlook changed - howto see all deleted files in pre-/post-commit hooks
Thanks Ryan and David for the info, that solved my problem. (I inspect the tree in a post-commit in the previous revision where the deleted files were still present.) What I was wondering though: if I commit a delete and run any svn command on the REV-1 version in the post-commit hook, is it guaranteed that in the meantime no other commits were run, thus making REV-1 invalid? Or in other words: pre-commit, commit and post-commit are atomic? Thanks, Jan On 8/4/11 9:24 AM, Ryan Schmidt wrote: On Aug 3, 2011, at 08:14, Jan Ciesko (GMAIL) wrote: I'd like to ask if there is a way to see which particular files have been deleted when a directory deletion has been commited. Example: I add to a repository BAR/Apps the folder Jacobi. With "svnlook changed "$REPOS"" in the post-commit hook I get the output: A BAR/Apps/Jacobi/ A BAR/Apps/Jacobi/LICENSE A BAR/Apps/Jacobi/Makefile A BAR/Apps/Jacobi/Readme A BAR/Apps/Jacobi/bin/ A BAR/Apps/Jacobi/src/ A BAR/Apps/Jacobi/src/jacobi.c On deleting the folder Jacobi from the repository and running $SVNLOOK changed "$REPOS" --transaction "$TXN" I'm getting only. D BAR/Apps/Jacobi/ Since I'm parsing a Readme file to update a TRAC front-end, I would very much need to see the individual files that were deleted in the Jacobi folder, including the Readme. Is there a way of getting this information? There's a slight confusion in your email, in that in a post-commit hook, you would not have a transaction ($TXN); you would have a revision ($REV). In a pre-commit hook you would have a transaction. When a commit comes in, Subversion creates a transaction, calls the pre-commit hook with that transaction to see if the commit is allowed to proceed; if it is, Subversion promotes the transaction to a revision, then calls the post-commit hook with that revision. One way to see what's in a directory would be to use "svnlook tree $REPOS $PATH_IN_REPOS". If you're calling this from a pre-commit hook, then the directory currently still exists in the repository and you can call it just like that, which will look at the HEAD of the repository. If we're in a post-commit hook, the directory has already been deleted from the HEAD, so you would need to look at the preceding revision ($REV - 1).
svn command line client SNI
Hi, is there any chance that the standart svn client supports SNI? Cheers Mario
RE: svn command line client SNI
> -Original Message- > From: Mario Brandt [mailto:jbl...@gmail.com] > Sent: vrijdag 12 augustus 2011 19:44 > To: users@subversion.apache.org > Subject: svn command line client SNI > > Hi, > is there any chance that the standart svn client supports SNI? If your Subversion client is compiled against a recent openssl and neon/serf version it supports SNI. (I think most binary distributions fall in this category) Bert > > Cheers > Mario
Re: svnlook changed - howto see all deleted files in pre-/post-commit hooks
On Aug 12, 2011, at 11:01, Jan Ciesko (GMAIL) wrote: > What I was wondering though: if I commit a delete and run any svn command on > the REV-1 version in the post-commit hook, is it guaranteed that in the > meantime no other commits were run, thus making REV-1 invalid? > Or in other words: pre-commit, commit and post-commit are atomic? Well let's think about each of those. The commit will not be finalized until after the pre-commit hook has run successfully. So the directory should continue to exist in the head of the repository for the duration of the pre-commit hook. It might be possible (though unlikely) that another developer will happen to delete the directory while the hook is running. To minimize the possibility of that messing up the script, the first thing the script should do is get the HEAD revision of the repository into a variable, and use that variable for the duration of the script: #!/bin/bash REPOS=$1 TXN=$2 SVNLOOK=/usr/bin/svnlook SED=/usr/bin/sed HEAD_REV=$($SVNLOOK youngest $REPOS) PATHS_IN_REPOS=$($SVNLOOK changed $REPOS -t $TXN | $SED -n -E 's/^D...(.*)$/\1/p') for PATH_IN_REPOS in $PATHS_IN_REPOS; do TREE=$($SVNLOOK tree $REPOS $PATH_IN_REPOS -r $HEAD_REV) ... (do something with $TREE) done The commit itself is atomic. That's one of the fundamental properties of Subversion and is well documented so we don't need to go into it further here. http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html "An svn commit operation publishes changes to any number of files and directories as a single atomic transaction." That leaves the post-commit. By this time the commit is finalized in the repository. So you can look at that new revision all you want and it's not going to change. Yes other commits might happen subsequently but your post-commit hook is called with the number of the newly-added revision, so just subtract one from that to find the last revision in which the directory still existed. #!/bin/bash REPOS=$1 REV=$2 SVNLOOK=/usr/bin/svnlook SED=/usr/bin/sed PREV_REV=$(($REV-1)) PATHS_IN_REPOS=$($SVNLOOK changed $REPOS -r $REV | $SED -n -E 's/^D...(.*)$/\1/p') for PATH_IN_REPOS in $PATHS_IN_REPOS; do TREE=$($SVNLOOK tree $REPOS $PATH_IN_REPOS -r $PREV_REV) ... (do something with $TREE) done These examples do not properly handle paths that contain spaces. Also, PATHS_IN_REPOS could contain files and/or directories; if you want only directories, you'll have to skip the files somehow.
