Windows junctions are not supported in Subversion 1.8.0 anymore
Hello, I'm working heavily with Windows junctions in my development environment, meaning that e.g. I check out a working copy in an Eclipse workspace using Subclipse and afterwards create a junction to my httpd cgi-bin directory. Please note that I do not link deeply into the working copy but create the junction to the working copy root. One example: The directory ...\Eclipse\Perl\some_project contains my working copy checked out using Subclipse, afterwards I manually create ...\httpd\cgi-bin\somewhere\some_project as a junction to the some_project folder in my Eclipse workspace. This allowed me to use Subclipse within Eclipse and TortoiseSVN in Windows Explorer depending on what I need to work on in my web application, which gets served by the current code base developed in Eclipse. This worked without any problems for years now with older versions of Subversion, but starting with 1.8.0 I get the following error: svn: E27: Symbolic links are not supported on this platform This is not bug 4383, my client doesn't crash, it simply shows me the error message. Besides that, the bug's status is still new, but the changelog for 1.8.1 mentioned it as fixed. http://subversion.tigris.org/issues/show_bug.cgi?id=4383 http://svn.apache.org/repos/asf/subversion/tags/1.8.1/CHANGES Is this behavior by design or a regression? I don't understand why Subversion needs to detect Windows junctions just to tell me that those are not supported. Couldn't it just use them as a plain directory like in older versions, including 1.7.x with the already new WC-NG format? Windows junctions are completely transparent to any application not caring about them. I find a bit annoying that Windows not only doesn't get the support for symbolic links, junctions etc. like other OS do, at least where possible, but that things which used to work before for years are now specially recognized just to tell me that they are not supported anymore. This is the second time were I relied on that things like hard or symbolic links, junctions etc. were treated at least transparently by Subversion and though would just work and got a bad surprise. I couldn't find any mention in the changelogs as well, besides the following: * optimize file/dir truename checks on Windows (r1435527) But looking at the code this seems to focus on names, not types of entries for directories or files. I would really appreciate if the old behavior could be restored or one can tell me what I'm doing wrong. Besides telling me to use some other OS, of course. ;-) Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Windows junctions are not supported in Subversion 1.8.0 anymore
On Thu, Jul 25, 2013 at 1:25 PM, Thorsten Schöning wrote: > Hello, > > I'm working heavily with Windows junctions in my development > environment, meaning that e.g. I check out a working copy in an > Eclipse workspace using Subclipse and afterwards create a junction to > my httpd cgi-bin directory. Please note that I do not link deeply into > the working copy but create the junction to the working copy root. One > example: The directory ...\Eclipse\Perl\some_project contains my > working copy checked out using Subclipse, afterwards I manually create > ...\httpd\cgi-bin\somewhere\some_project as a junction to the > some_project folder in my Eclipse workspace. > > This allowed me to use Subclipse within Eclipse and TortoiseSVN in > Windows Explorer depending on what I need to work on in my web > application, which gets served by the current code base developed in > Eclipse. This worked without any problems for years now with older > versions of Subversion, but starting with 1.8.0 I get the following > error: > > svn: E27: Symbolic links are not supported on this platform > > This is not bug 4383, my client doesn't crash, it simply shows me the > error message. Besides that, the bug's status is still new, but the > changelog for 1.8.1 mentioned it as fixed. > > http://subversion.tigris.org/issues/show_bug.cgi?id=4383 > http://svn.apache.org/repos/asf/subversion/tags/1.8.1/CHANGES > Reading symbolic links on Windows Vista and later is implemented on trunk in r1501251 [1]: [[[ Implement reading symbolic links on Windows Vista or later. This fix issues with working copies located in symlinked folders. ]]] Maybe it worth to backport this change to 1.8.x to fix reported issue? [1] http://svn.apache.org/r1501251 -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Backup strategy sanity check
On 7/24/2013 4:21 PM, Les Mikesell wrote: Is that better than using svnsync from a remote server plus some normal file backup approach for the conf/hooks directories? Not sure, I have not tried out svnsync. We also don't use post-commit hooks (yet). I am under the impression that hotcopy does grab conf/hooks stuff while dump does not. But can't find anything in the svnbook that says either way at the moment. ... http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.backup svnsync definitely does not handle some things: The primary disadvantage of this method is that only the versioned repository data gets synchronized—repository configuration files, user-specified repository path locks, and other items that might live in the physical repository directory but not inside the repository's virtual versioned filesystem are not handled by svnsync. ... We also run a svnadmin verify on the rdiff-backup directories each week, combined with verifying the checksums on the rdiff-backup files. The combination of checksums on the rdiff-backups plus 26W of snapshots that I can restore to is, I feel, pretty safe. I try to reexamine the backup strategy every 6 months, but I think I'm in a good spot now with the svnadmin hotcopy / rdiff-backup setup. Which also makes it easy for us to rsync the rdiff-backup folder to an offsite server. Downside is the delay introduced by doing hotcopy only once per day. So worst case might mean the lost of 20-48 hours of commits. A more frequent svnsync / incremental hotcopy triggered by a post-commit hook would have a much smaller delay.
Re: Windows junctions are not supported in Subversion 1.8.0 anymore
Guten Tag Ivan Zhakov, am Donnerstag, 25. Juli 2013 um 12:04 schrieben Sie: > Reading symbolic links on Windows Vista and later is implemented on > trunk in r1501251 [1]: I hope this will work with junctions, too, as from my understanding both are technically different, but even MSDN often just refers to "symbolic links", but mentions reparse points later on, which implied Junctions when "true" symbolic links didn't exist in NTFS yet. > Related topics > Symbolic Links > Hard Links and Junctions http://msdn.microsoft.com/en-us/library/windows/desktop/aa363878(v=vs.85).aspx > Maybe it worth to backport this change to 1.8.x to fix reported issue? Definitely +1 from me or maybe consider restoring the old behavior were Subversion didn't care about Junctions at all, but simply worked. Does Subversion store absolute paths to working copies inside the working copy or why should it care to resolve junctions(/links) in new versions? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Windows junctions are not supported in Subversion 1.8.0 anymore
On Thu, Jul 25, 2013 at 02:04:30PM +0400, Ivan Zhakov wrote: > Reading symbolic links on Windows Vista and later is implemented on > trunk in r1501251 [1]: > [[[ > Implement reading symbolic links on Windows Vista or later. This fix > issues with working copies located in symlinked folders. > ]]] > > Maybe it worth to backport this change to 1.8.x to fix reported issue? > > [1] http://svn.apache.org/r1501251 I would say it's a new feature, not a bug fix. Which would mean that it needs to wait for 1.9.
Re: Backup strategy sanity check
On Wed, Jul 24, 2013 at 11:08:28PM -0400, Nico Kadel-Garcia wrote: > On Wed, Jul 24, 2013 at 2:59 PM, Andy Levy wrote: > > I'm planning my upgrade to SVN 1.8 & to go along with it, setting up a > > new backup process. Here's what I'm thinking: > > > > * Monday overnight, take a full backup (svnadmin hotcopy, then > > compress the result for storage) > > Insufficient. You also need the Apache or svnserve or SSH configs, and > the varoius commit scripts from the base repository, along with their > ownership and permissions. Tarballs are good, "rsync -avH" is even > better for imaging such loactions in a decodable format. Well, actually, a hotcopy includes hook scripts and config stored inside the repository directory. A dump file does not. I suppose you're confusing the two? Andy, if you're upgrading to 1.8, perhaps the new incremental hotcopy feature can help you: http://subversion.apache.org/docs/release-notes/1.8.html#incremental-hotcopy You might also want to consider making use of 'svnadmin freeze': http://subversion.apache.org/docs/release-notes/1.8.html#svnadmin-freeze
Re: Backup strategy sanity check
On Wed, Jul 24, 2013 at 03:22:11PM -0400, Thomas Harold wrote: > What we might do once 1.8 server is stable is switch to doing the > new "incremental" style hotcopy on Mon-Sat evenings and do a full > hotcopy on Sun. In Subversion 1.8, a full hotcopy is implemented as an incremental hotcopy into an emtpy target repository. There is no point in copying everything again on a Sunday because that just repeats work that's already been done.
Re: Windows junctions are not supported in Subversion 1.8.0 anymore
Guten Tag Stefan Sperling, am Donnerstag, 25. Juli 2013 um 13:23 schrieben Sie: > I would say it's a new feature, not a bug fix. Which would mean that > it needs to wait for 1.9. But things worked in Subversion 1.7.x. It's not about versioned links or things like that, not even anything unversioned inside the working copy, it's about junctions to working copy roots outside the working copy which Subversion shouldn't care about. Though I would expect that unversioned junctions in a working copy should work again, too. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Subversion 1.7.11 and 1.8.1 SRPM bulding tools updated on github
Good morning: I see that 1.7.11 and 1.8.1 were just released, and I was up doing a software deployment with folks in India last night. So for anyone working in RHEL or CentOS or Scientific Linux worls, I've been publishing tools to build those as RPM's over at github.com, and I've just updated them for the new releases. https://github.com/nkadel/subversion-1.8.x-srpm https://github.com/nkadel/subversion-1.7.x-srpm Neither compiles on anything older than RHEL 6, due to too many newer dependencies. I'll renew my efforts to get them updated in repoforge, so they're available as public RPM's. Note that both git repos do not hold the tarballs, but hte .spec files say where to get them from source. And the "Makefile" is built around using "mock" to compile the systems or to build them locally. Suversion 1.8.x also has a "libserf" depndency that requires the "EPEL" repository. Nico Kadel-Garcia
RE: Windows junctions are not supported in Subversion 1.8.0 anymore
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 25 juli 2013 13:24 > To: Ivan Zhakov > Cc: Subversion Development; users@subversion.apache.org; Thorsten > Schöning > Subject: Re: Windows junctions are not supported in Subversion 1.8.0 > anymore > > On Thu, Jul 25, 2013 at 02:04:30PM +0400, Ivan Zhakov wrote: > > Reading symbolic links on Windows Vista and later is implemented on > > trunk in r1501251 [1]: > > [[[ > > Implement reading symbolic links on Windows Vista or later. This fix > > issues with working copies located in symlinked folders. > > ]]] > > > > Maybe it worth to backport this change to 1.8.x to fix reported issue? > > > > [1] http://svn.apache.org/r1501251 > > I would say it's a new feature, not a bug fix. Which would mean that > it needs to wait for 1.9. In 1.7 we didn't try reading symlinks for opening a working copy, while in 1.8 and trunk we do try to read the symlink. So working copies that did work in 1.7 are not working any more. I would call that a regression. But I don't know if reading the symlink to find the working copy is the proper solution here. But we had the same problem when we discussed that bit of code last time. Bert
RE: Mixing recursive and non-recursive commits
I understand the copy and delete scenarios. They would have to be identified up front (with perhaps a behind the scenes svn status -u --depth=empty on all the parent directories w/ respect to the command line objects) and if they are replaced or added via copy then it would error out and make the user handle these because they need to be recursive operations. The problem with just passing a list of targets is just that... coming up with the entire list of targets below the original target recursively and then above (parents). This could be a long list to have add/figure out when it would seem the tool could just do this when a --parents option was added. So what's needed in other words is when --parents is added it recursively looks below the targets given and gathers the usual targets that need to be committed. It then looks up through the parents and adds each parent directory depending on whether each is a simple add or not. It then does the commit with a --depth=empty on all targets and proceeds. I don't know why this is should be complicated to do from the command line when GUI clients are already doing this today. I would use a GUI client to do this work in most cases but GUI's don't work as well when defining wildcards/filtering (*/*/file for example for a commit target). Eric -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Wednesday, July 24, 2013 5:24 PM To: Braun, Eric Cc: users@subversion.apache.org; Moe, Mark Subject: Re: Mixing recursive and non-recursive commits On Wed, Jul 24, 2013 at 07:32:20PM +, Braun, Eric wrote: > The enhancement would be to include only parents marked for addition. > Nothing special for prop changes as you don't want to commit these later if > the directory was already committed (unless explicitly stated). > > So, I think's a rather simple request. If commit --parents is loaded then > any parent directories for the given command line targets that are in an add > state should be included in the targets passed on. > > Eric What would svn commit --parents do if the newly added parents are replacing a deleted item in the working copy? It seems svn would then have to commit a replacement instead of an addition. In which case this option cannot claim to be scoped to just additions, because a deletion needs to be committed as part of the replacement. The same questions applies to added items which are inside copies. Copies can only be committed recursively due to the way cheap copies are implemented in the repository. That would mean that not only parents of the explicit commit target would be committed, but also any other children of those parents. If the --parents option did nothing for copied and replaced items, it would probably have to error out if those occur. For example, the following would commit A and A/B: svn mkdir A svn mkdir A/B svn commit --parents A/B But the following would have to error out or commit the deletion of the original A, not just an addition: svn rm A svn mkdir A svn mkdir A/B svn commit --parents A/B And this would also error out or commit any children of C along with the child B, effectively committing C recursively, which defeats the idea of the --parents option: svn cp A C svn mkdir C/B svn commit --parents C/B So, due to the recursive nature of copies, the above would be equivalent to: svn cp A C svn mkdir C/B svn commit C I'm not sure how this behaviour can be defined in a consistent way. What about passing the right list of commit targets instead of adding a new --parents option? Note that the list can be passed via a file using the --targets option. Perhaps you could generate a file that includes the proper list of targets, and then run the commit? [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: Backup strategy sanity check
On Thu, Jul 25, 2013 at 7:27 AM, Stefan Sperling wrote: > On Wed, Jul 24, 2013 at 11:08:28PM -0400, Nico Kadel-Garcia wrote: >> On Wed, Jul 24, 2013 at 2:59 PM, Andy Levy wrote: >> > I'm planning my upgrade to SVN 1.8 & to go along with it, setting up a >> > new backup process. Here's what I'm thinking: >> > >> > * Monday overnight, take a full backup (svnadmin hotcopy, then >> > compress the result for storage) >> >> Insufficient. You also need the Apache or svnserve or SSH configs, and >> the varoius commit scripts from the base repository, along with their >> ownership and permissions. Tarballs are good, "rsync -avH" is even >> better for imaging such loactions in a decodable format. > > Well, actually, a hotcopy includes hook scripts and config stored > inside the repository directory. A dump file does not. I suppose > you're confusing the two? > > Andy, if you're upgrading to 1.8, perhaps the new incremental > hotcopy feature can help you: > http://subversion.apache.org/docs/release-notes/1.8.html#incremental-hotcopy I am planning on going to 1.8.x, so this does look very interesting. It would definitely simplify things. > You might also want to consider making use of 'svnadmin freeze': > http://subversion.apache.org/docs/release-notes/1.8.html#svnadmin-freeze That one won't work for me. I'm not in control of the enterprise backup software, so I don't even know when the backup will even happen (I know it'll be within a many-hours-wide window). I asked the sysadmin who is in charge of that software and he would have to research whether it's even possible to run a script to freeze & unfreeze the repository when the system gets to that server. Even if it is possible, the implementation timeline will be long.
Problem with SSL Client auth and libserf
Hello, I am experiencing re-negotiation issues namely connection closed when trying to use a subversion client >=1.8 against an svn server running Debian Wheezy apache 2.2.22 libapache 1.8.1 subversion 1.8.1 openssl 1.0.1e with ssl client auth. I have now spent about 4 hours of searching through old ssl client auth errors in the openssl issues, subversion maillinglist and tried the following combinations of client libraries and binaries against the server mentioned above: * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1 * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive the following error on the client side, regardless of the openssl version: svn: E120108: Unable to connect to a repository at URL 'https://example.com/svn/myrepo' svn: E120108: Error running context: The server unexpectedly closed the connection. Disabling the 'SSLVerifyClient Require' directive yields a successful listing of the svn content, so this really appears to be related to client auth. Using an svn client with libneon also yields a successful repository listing so this points quite directly at libserf. On the server side the error messages in debug mode look like this: ... initial ssl connection setup completes ... [Thu Jul 25 16:20:12 2013] [info] Initial (No.1) HTTPS request received for child 77 (server inet-svn.net.t-labs.tu-berlin.de:443) [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(510): [client ] Changed client verification type will force renegotiation [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1554): [client ] filling buffer, max size 131072 bytes [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1606): [client ] total of 131 bytes in buffer, eos=1 [Thu Jul 25 16:20:12 2013] [info] [client ] Requesting connection re-negotiation [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3] [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(764): [client ] Performing full renegotiation: complete handshake protocol (client does support secure renegotiation) [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL: Handshake: start [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop: SSL renegotiate ciphers [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop: SSLv3 write hello request A [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop: SSLv3 flush data [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop: SSLv3 write hello request C [Thu Jul 25 16:20:12 2013] [info] [client ] Awaiting re-negotiation handshake [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL: Handshake: start [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop: before accept initialization [Thu Jul 25 16:20:22 2013] [info] [client ] Request body read timeout [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3] [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_kernel.c(1903): OpenSSL: Exit: error in SSLv3 read client hello B [Thu Jul 25 16:20:22 2013] [error] [client ] Re-negotiation handshake failed: Not accepted by client!? [Thu Jul 25 16:20:22 2013] [debug] mod_deflate.c(615): [client ] Zlib: Compressed 0 to 2 : URL /svn/bernd So either the client sent garbage or not what the server expects or there is some kind of hiccup in the server libraries? If anyone could point me to a way to further debug this or a solution, I'd be very gracious -- Technische Universität Berlin - FGINET Bernd May System Administration Sekr. TEL 16 Ernst-Reuter-Platz 7 10587 BERLIN GERMANY Mobile: 0160/90257737 E-Mail: be...@inet.tu-berlin.de WWW:inet.tu-berlin.de signature.asc Description: OpenPGP digital signature
Re: Mixing recursive and non-recursive commits
On Thu, Jul 25, 2013 at 02:01:23PM +, Braun, Eric wrote: > I don't know why this is > should be complicated to do from the command line when GUI clients are > already doing this today. My concern is not about whether this would be complicated to implement. It wouldn't be. My concern is that your proposal is creating a command line option that will cause a commit to succeed or fail based on the order of operations the user carried out in a working copy. svn mkdir A svn mkdir A/B svn commit --parents A/B commit succeeds svn rm A svn mkdir A svn mkdir A/B svn commit --parents A/B commit fails svn mkdir A svn mkdir A/B svn commit A/B commit succeeds svn rm A svn mkdir A svn mkdir A/B svn commit A/B commit succeeds I don't think this is intuitive behaviour. It is sensible from the point of view of your use case, no doubt. However, I'm concerned about creating an option that has inconsistent behaviour depending on working copy state. You're saying some GUI clients had this feature already. I'd like to know how they deal with the replacement and copy cases I've pointed out. I believe it's quite likely that they perform recursive commits in those cases, which defeats the point of the proposed option.
Re: Problem with SSL Client auth and libserf
Hi, On Thu, Jul 25, 2013 at 4:25 PM, Bernd May wrote: > Hello, > > I am experiencing re-negotiation issues namely connection closed when > trying to use a subversion client >=1.8 against an svn server running > > Debian Wheezy > apache 2.2.22 > libapache 1.8.1 > subversion 1.8.1 > openssl 1.0.1e > > with ssl client auth. > > I have now spent about 4 hours of searching through old ssl client auth > errors in the openssl issues, subversion maillinglist and tried the > following combinations of client libraries and binaries against the > server mentioned above: > > * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1 > * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e > > Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive > the following error on the client side, regardless of the openssl version: > > svn: E120108: Unable to connect to a repository at URL > 'https://example.com/svn/myrepo' > svn: E120108: Error running context: The server unexpectedly closed the > connection. > > Disabling the 'SSLVerifyClient Require' directive yields a successful > listing of the svn content, so this really appears to be related to > client auth. > Using an svn client with libneon also yields a successful repository > listing so this points quite directly at libserf. > > On the server side the error messages in debug mode look like this: > > ... initial ssl connection setup completes ... > [Thu Jul 25 16:20:12 2013] [info] Initial (No.1) HTTPS request received > for child 77 (server inet-svn.net.t-labs.tu-berlin.de:443) > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(510): [client > ] Changed client verification type will force renegotiation > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1554): [client > ] filling buffer, max size 131072 bytes > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1606): [client > ] total of 131 bytes in buffer, eos=1 > [Thu Jul 25 16:20:12 2013] [info] [client ] Requesting connection > re-negotiation > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O > error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3] > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(764): [client > ] Performing full renegotiation: complete handshake protocol > (client does support secure renegotiation) > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL: > Handshake: start > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: > Loop: SSL renegotiate ciphers > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: > Loop: SSLv3 write hello request A > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: > Loop: SSLv3 flush data > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: > Loop: SSLv3 write hello request C > [Thu Jul 25 16:20:12 2013] [info] [client ] Awaiting > re-negotiation handshake > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL: > Handshake: start > [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL: > Loop: before accept initialization > [Thu Jul 25 16:20:22 2013] [info] [client ] Request body read timeout > [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O > error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3] > [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_kernel.c(1903): OpenSSL: > Exit: error in SSLv3 read client hello B > [Thu Jul 25 16:20:22 2013] [error] [client ] Re-negotiation > handshake failed: Not accepted by client!? > [Thu Jul 25 16:20:22 2013] [debug] mod_deflate.c(615): [client ] > Zlib: Compressed 0 to 2 : URL /svn/bernd > Renegotiation has been tested in serf, maybe it doesn''t work in all cases. > > So either the client sent garbage or not what the server expects or > there is some kind of hiccup in the server libraries? > > If anyone could point me to a way to further debug this or a solution, > I'd be very gracious Enabling logging in serf will probably give you more detailed info on the failure on the client side. Logging can be activated by setting these flags in serf_private.h and then rebuilding serf: #define SSL_VERBOSE 1 #define CONN_VERBOSE 1 #define SOCK_VERBOSE 1 If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but the info you'll need will be at the end. Alternatively you can upgrade to serf 1.3.0 where ssl logging has been cleaned up. You can send the log files to the list or to me privately, I'll have a look. Lieven > -- > Technische Universität Berlin - FGINET > > Bernd May > > System Administration > Sekr. TEL 16 > Ernst-Reuter-Platz 7 > 10587 BERLIN > GERMANY > > Mobile: 0160/90257737 > E-Mail: be...@inet.tu-berlin.de > WWW:inet.tu-berlin.de >
RE: Mixing recursive and non-recursive commits
I think if the documentation for --parents says it will do a non-recursive commit of any intermediate directories and if any of these are marked as replaced or copied it will error out then this is sufficient documentation for the user. Yes, the scenarios you listed are correct but with the right info I think it's acceptable. The GUI I was referring to was WanDisco's smartSVN. It handles both scenarios properly by not showing the intermediate directory in the commit list thus causing an error for not having all targets defined if the user proceeds to commit the lower level change. TortoiseSVN appears to be the same way. Both however automatically add the intermediate directories to the commit list if they newly added. What I am trying to enable is the ability to add and commit files deep in hierarchies w/o having to specify intermediate directories. We were using simple examples but often we will have many level structures that are previously committed and create new structures beneath it along with modifying the existing. We want to add/commit just the new directories/files specified and not the other areas. This achievable with a GUI but very hard to filter out just what you want. Eric -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Thursday, July 25, 2013 10:21 AM To: Braun, Eric Cc: users@subversion.apache.org; Moe, Mark Subject: Re: Mixing recursive and non-recursive commits On Thu, Jul 25, 2013 at 02:01:23PM +, Braun, Eric wrote: > I don't know why this is > should be complicated to do from the command line when GUI clients are > already doing this today. My concern is not about whether this would be complicated to implement. It wouldn't be. My concern is that your proposal is creating a command line option that will cause a commit to succeed or fail based on the order of operations the user carried out in a working copy. svn mkdir A svn mkdir A/B svn commit --parents A/B commit succeeds svn rm A svn mkdir A svn mkdir A/B svn commit --parents A/B commit fails svn mkdir A svn mkdir A/B svn commit A/B commit succeeds svn rm A svn mkdir A svn mkdir A/B svn commit A/B commit succeeds I don't think this is intuitive behaviour. It is sensible from the point of view of your use case, no doubt. However, I'm concerned about creating an option that has inconsistent behaviour depending on working copy state. You're saying some GUI clients had this feature already. I'd like to know how they deal with the replacement and copy cases I've pointed out. I believe it's quite likely that they perform recursive commits in those cases, which defeats the point of the proposed option. [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: Problem with SSL Client auth and libserf
Hi Bernd, On Thu, Jul 25, 2013 at 5:56 PM, Lieven Govaerts wrote: > Hi, > > On Thu, Jul 25, 2013 at 4:25 PM, Bernd May > wrote: >> Hello, >> >> I am experiencing re-negotiation issues namely connection closed when >> trying to use a subversion client >=1.8 against an svn server running >> >> Debian Wheezy >> apache 2.2.22 >> libapache 1.8.1 >> subversion 1.8.1 >> openssl 1.0.1e >> >> with ssl client auth. >> >> I have now spent about 4 hours of searching through old ssl client auth >> errors in the openssl issues, subversion maillinglist and tried the >> following combinations of client libraries and binaries against the >> server mentioned above: >> >> * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1 >> * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e >> >> Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive >> the following error on the client side, regardless of the openssl version: >> >> svn: E120108: Unable to connect to a repository at URL >> 'https://example.com/svn/myrepo' >> svn: E120108: Error running context: The server unexpectedly closed the >> connection. >> >> Disabling the 'SSLVerifyClient Require' directive yields a successful >> listing of the svn content, so this really appears to be related to >> client auth. >> Using an svn client with libneon also yields a successful repository >> listing so this points quite directly at libserf. [..] > > Enabling logging in serf will probably give you more detailed info on > the failure on the client side. > Logging can be activated by setting these flags in serf_private.h and > then rebuilding serf: > #define SSL_VERBOSE 1 > #define CONN_VERBOSE 1 > #define SOCK_VERBOSE 1 > > > If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but > the info you'll need will be at the end. Alternatively you can upgrade > to serf 1.3.0 where ssl logging has been cleaned up. You can send the > log files to the list or to me privately, I'll have a look. the logs you sent (via private mail) did contain all the requested info, but it's not enough to analyse the root cause. However, I can reproduce this by accessing my test repo with svn trunk and serf trunk over https, with the "SSLVerifyClient Require" line added to the server config. My server setup does not require client certificates, so that is not a factor here. Would you mind summarising this problem in a ticket in the serf issue tracker at https://code.google.com/p/serf/issues/list ? I'll see what I can find. Lieven >> -- >> Technische Universität Berlin - FGINET >> >> Bernd May >> >> System Administration >> Sekr. TEL 16 >> Ernst-Reuter-Platz 7 >> 10587 BERLIN >> GERMANY >> >> Mobile: 0160/90257737 >> E-Mail: be...@inet.tu-berlin.de >> WWW:inet.tu-berlin.de >>
Re: Problem with SSL Client auth and libserf
On Thu, Jul 25, 2013 at 8:53 PM, Lieven Govaerts wrote: > Hi Bernd, > > On Thu, Jul 25, 2013 at 5:56 PM, Lieven Govaerts wrote: >> Hi, >> >> On Thu, Jul 25, 2013 at 4:25 PM, Bernd May >> wrote: >>> Hello, >>> >>> I am experiencing re-negotiation issues namely connection closed when >>> trying to use a subversion client >=1.8 against an svn server running >>> >>> Debian Wheezy >>> apache 2.2.22 >>> libapache 1.8.1 >>> subversion 1.8.1 >>> openssl 1.0.1e >>> >>> with ssl client auth. >>> >>> I have now spent about 4 hours of searching through old ssl client auth >>> errors in the openssl issues, subversion maillinglist and tried the >>> following combinations of client libraries and binaries against the >>> server mentioned above: >>> >>> * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1 >>> * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e >>> >>> Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive >>> the following error on the client side, regardless of the openssl version: >>> >>> svn: E120108: Unable to connect to a repository at URL >>> 'https://example.com/svn/myrepo' >>> svn: E120108: Error running context: The server unexpectedly closed the >>> connection. >>> >>> Disabling the 'SSLVerifyClient Require' directive yields a successful >>> listing of the svn content, so this really appears to be related to >>> client auth. >>> Using an svn client with libneon also yields a successful repository >>> listing so this points quite directly at libserf. > > [..] > >> >> Enabling logging in serf will probably give you more detailed info on >> the failure on the client side. >> Logging can be activated by setting these flags in serf_private.h and >> then rebuilding serf: >> #define SSL_VERBOSE 1 >> #define CONN_VERBOSE 1 >> #define SOCK_VERBOSE 1 >> >> >> If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but >> the info you'll need will be at the end. Alternatively you can upgrade >> to serf 1.3.0 where ssl logging has been cleaned up. You can send the >> log files to the list or to me privately, I'll have a look. > > > the logs you sent (via private mail) did contain all the requested > info, but it's not enough to analyse the root cause. > > However, I can reproduce this by accessing my test repo with svn trunk > and serf trunk over https, with the "SSLVerifyClient Require" line > added to the server config. My server setup does not require client > certificates, so that is not a factor here. This last sentence doesn't make a lot of sense, it doesn't work because I hadn't configured my client certificate. I still can't get it to work with a valid client certificate matching the server certs, so need to look further. L. > Would you mind summarising this problem in a ticket in the serf issue > tracker at https://code.google.com/p/serf/issues/list ? I'll see what > I can find. > > Lieven > >>> -- >>> Technische Universität Berlin - FGINET >>> >>> Bernd May >>> >>> System Administration >>> Sekr. TEL 16 >>> Ernst-Reuter-Platz 7 >>> 10587 BERLIN >>> GERMANY >>> >>> Mobile: 0160/90257737 >>> E-Mail: be...@inet.tu-berlin.de >>> WWW:inet.tu-berlin.de >>>
