Re: Unable to access our SVN server using SVN 1.8 client

What error do you see in TortoiseSVN or other 1.8 clients? Subversion 1.8 will look at parent directories to find inherited properties, but it will just ignore properties on directories which it can't read. Bert Sent from Windows Mail From: Johannes Michler Sent: ‎Saturday‎,

Re: svnsync sync error parsing arguments

Guten Tag Joel Rees, am Montag, 24. Februar 2014 um 23:47 schrieben Sie: > --- > $ svnsync sync https://svn.sourceforge.jp/svnroot/bif-c/ > https://svn.code.sf.net/p/bif-c --username reiisi > svnsync: より詳しく知りたいときは 'svnsync help' を試してみてください > svnsync: 引数をパースする際にエラーが生じました > -

separating out unwanted changes

Hi, I wonder if someone could give me some advice on the following situation. Its probably pretty simple but my svn knowledge has dropped off a bit. An unstable dev branch was reintegrated and then a bunch of subsequent fixes were made on the mainline, mixed in with other development. Stability

RE: separating out unwanted changes

That is one option. The other option is creating a maintenance branch from the old revision, where things were still ok (e.g. right before the reintegrate) and then merging the changes from trunk to the branch that you want to keep. It really depends on whether you want to have 'trunk' to b

RE: separating out unwanted changes

Thanks for confirming that Bert. I'd prefer to keep the trunk stable so I've recommended the reverse merge approach. From: Bert Huijben [mailto:b...@qqmail.nl] Sent: 25 February 2014 10:38 To: James French; users@subversion.apache.org Subject: RE: separating out unwanted changes That is one opti

AW: Subversion exception! (common_util.c line 211)

Hello list, today the same exception occurred with TortoiseSVN version 1.8.5 Here the complete version information: * TortoiseSVN 1.8.5, Build 25224 - 64 Bit , 2014/02/18 20:05:11 * Subversion 1.8.8, -release * apr 1.5.0 * apr-util 1.5.3 * serf 1.3.4 * OpenSSL 1.0.1f 6 Jan 2014 * zlib 1.2.8 Perh

Re: svnsync sync error parsing arguments

On Tue, Feb 25, 2014 at 5:34 PM, Thorsten Schöning wrote: > Guten Tag Joel Rees, > am Montag, 24. Februar 2014 um 23:47 schrieben Sie: > >> --- >> $ svnsync sync https://svn.sourceforge.jp/svnroot/bif-c/ >> https://svn.code.sf.net/p/bif-c --username reiisi >> svnsync: より詳しく知りたいときは 'svn

Silently corrupted WC?

Hi, I recently ran into an issue with subversion that I don't know if it is a bug or something I'm not understanding, so I figured I'd ask here in case I run into something similar in the future. I'm running a Jenkins server for some ci-jobs for a project. The server checks out the code from s

Re: Unable to access our SVN server using SVN 1.8 client

Hi Bert, well the client is asking over and over again and finally gives up: C:\Users\jmichler\Desktop\test>svn co https://SERVER/svn/PROJEKTE/KUNDE1/trunk/R12/ Authentication realm: PROMATIS Authentifizierung Password for 'user1': Authentication realm:

Re: Unable to access our SVN server using SVN 1.8 client

On 2/25/14, 11:04 AM, Johannes Michler wrote: > well the client is asking over and over again and finally gives up: > C:\Users\jmichler\Desktop\test>svn co > https://SERVER/svn/PROJEKTE/KUNDE1/trunk/R12/ > Authentication realm: PROMATIS Authentifizierung > Password for 'user1'

RE: Subversion exception! (common_util.c line 211)

Hi, I'm guessing that you tried to commit a delete somewhere in a directory that you just copied and didn't commit yet. In this specific case I finally found a reproduction for this specific assertion, which requires a few more conditions. (See http://svn.apache.org/view

Re: Unable to access our SVN server using SVN 1.8 client

Hi Ben, well I'm using Apache 2.2: apache2 -v Server version: Apache/2.2.22 (Debian) Server built: Jan 31 2014 18:55:37 Is there a workaround for 2.2 as well? Regards, Johannes 2014-02-25 20:36 GMT+01:00 Ben Reser : > On 2/25/14, 11:04 AM, Johannes Michler wrote: > > well the client is ask

Re: Unable to access our SVN server using SVN 1.8 client

On 2/25/14, 11:44 AM, Johannes Michler wrote: > well I'm using Apache 2.2: > apache2 -v > Server version: Apache/2.2.22 (Debian) > Server built: Jan 31 2014 18:55:37 > > Is there a workaround for 2.2 as well? Yeah just realized that looking at your original mail. 2.2 shouldn't have that behavi

Re: Unable to access our SVN server using SVN 1.8 client

Well but by looking into my logfiles I see that my server is indeed sending HTTP-401. Is this the problem? Regards, Johannes 2014-02-25 20:51 GMT+01:00 Ben Reser : > On 2/25/14, 11:44 AM, Johannes Michler wrote: > > well I'm using Apache 2.2: > > apache2 -v > > Server version: Apache/2.2.22 (De

Re: Unable to access our SVN server using SVN 1.8 client

On 2/25/14, 12:03 PM, Johannes Michler wrote: > Well but by looking into my logfiles I see that my server is indeed sending > HTTP-401. Is this the problem? I don't think there's really anything that a 1.8 client can or should do different here. The server is saying "give me authn credentials" an

AW: Unable to access our SVN server using SVN 1.8 client

Hi, Ben, Von: Ben Reser [mailto:b...@reser.org] > > On 2/25/14, 12:03 PM, Johannes Michler wrote: > > Well but by looking into my logfiles I see that my server is indeed > > sending HTTP-401. Is this the problem? > > I don't think there's really anything that a 1.8 client can or should do > diff

Re: Silently corrupted WC?

On Tue, Feb 25, 2014 at 3:09 PM, Chris wrote: > Hi, > > I recently ran into an issue with subversion that I don't know if it is a bug > or something I'm not understanding, so I figured I'd ask here in case I run > into something similar in the future. > > I'm running a Jenkins server for some ci

Re: Unable to access our SVN server using SVN 1.8 client

On 2/25/14, 12:52 PM, Ben Reser wrote: > 2) Write a custom authz hook that always returns HTTP_FORBIDDEN that hooks > after the ldap module. Configure your custom module to be turned on for your > location. Then set 'AuthzLDAPAuthoritative off', meaning that the ldap module > will DECLINE and the

Re: AW: Unable to access our SVN server using SVN 1.8 client

On 2/25/14, 1:25 PM, Markus Schaber wrote: > I tend to think it might be a sensible behavior to not prompt for > Authentication on the client side during specifically this kind of > upwards tree walk when the client successfully authenticated for the > "main" request, and later fails with the sam

AW: Subversion exception! (common_util.c line 211)

Hi Bert, > I'm guessing that you tried to commit a delete somewhere in a directory that > you just copied and didn't commit yet. Yes it is very, very likely that something like that was part of what I've tried to commit > I'm nominating the fix for this issue for 1.8.9. Thank you, Reinhard