Re: svnserve bug leading blanks - need add function trim

2014-09-18 Thread Branko Čibej
On 18.09.2014 08:28, Алексей Дорбах wrote:
>
> Hello,
>
> My name is Alexey Loginov from Skylink company located in Russia.
> I installed sub-version and Tortoise here in my environment but I'm
> facing a problem with password authentication.
> When I uncomment line at svnserve.conf commented with #
> ' anon-access=none' is leading space character remain at begin of line
> Then I trying to connecting to repository with Tortoise client and it
> shows me an error
> "svn: /var/www/snv/svnserve.conf:12: Option Expected"
> If I delete that remaining space character - all is OK.
>
> Please add a trim function that remove leading and trailing blanks
> when parses lines of config files

I'm afraid not. The format of the config file is well defined: sections,
options and comments must all start in the first column of a line.

-- Brane



Re: svnserve errors in the system logs

2014-09-18 Thread Philip Martin
Trent Fisher  writes:

> I just discovered tons of spam in /var/log/messages on one of my
> servers (Linux RHEL 5.8 with Subversion 1.8.9) :
>
> Sep 17 06:30:41 adc4110305 svnserve: sql_select option missing
> Sep 17 06:30:41 adc4110305 svnserve: auxpropfunc error no mechanism available
> Sep 17 06:30:41 adc4110305 svnserve: auxpropfunc error invalid parameter 
> supplied
>
> This error pops up everytime someone accesses a repository via
> svn+ssh.  It doesn't seem to hinder functionality.  I can reproduce
> this simply by running "ssh adc4110305 svnserve -t" (the error pops up
> before I can type anything).
>
> From what I have gathered from my internet searches, it sounds like
> Cyrus SASL is getting involved.  Though I don't understand why, as I
> thought the tunnel mode was supposed to use the pre-authenticated
> username.  I tried messing with /etc/sasl2/svn.conf but only managed
> to make it worse.  One person suggested (on this very mailing list 5
> years ago) removing the relevant cyrus-sasl packages, but that doesn't
> seem like a good idea.  What's the correct way of fixing this?
>
> I should note that I built Subversion myself, so if I need to rebuild
> with some different config options to disable this behavior, I can do
> so.

That error comes from the SASL library when it loads the SQL plugin and
then finds that SASL has not been configured to use SQL.  At present
svnserve calls sasl_server_init() at startup and I suppose we could
delay the call until we know that SASL is required, but the problem
would still occur when a repository used SASL.  There may be a way to
tell SASL not to load the SQL plugin but I have not been able to find
it.  I avoid installing the libsasl2-modules-sql package on my system.

You can build Subversion using --without-sasl.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*


Re: Error while replaying commit

2014-09-18 Thread Philip Martin
Trent Fisher  writes:

> I have an svnsync replica which is running into this error when I
> sync: "svnsync: E210008: Error while replaying commit".
>
> I was able to work around the problem by doing an svnadmin dump of the
> troublesome revision and loading it on the other server, then tweaking
> the svnsync properties.  However, I decided to spend a bit of time
> trying to dig down to the root cause (since this error pops up
> periodically).
>
> I am doing the svnsync via an svn+ssh url, doing the svnsync as a
> pull, and I am running as the owner of the repository (on both hosts),
> so there should be no permissions issues.  Both machines are running
> SVN 1.8.9 on Linux.  To narrow it down to whether the problem is on
> the sending or the receiving side (the error message implies the
> latter), I ran svnrdump:
>
> svnrdump dump --incremental -r511 svn+ssh://scmadm@somehost/some/svn/repos
> svnrdump: E210008: Error while replaying commit
>
> Ok, so I narrowed it down to being on the sending side. I ran svnrdump
> on the server itself using a file: url, and that worked. Then I
> brought up an svnserve process and tried using an svn: url, and that
> worked.  So it seems that SSH is getting in the way somehow.  I ran
> the first svnrdump with "--config-option config:tunnels:ssh='$SVN_SSH
> ssh -vvv'" but couldn't see anything wrong from what I could decipher.
>
> I need to move on to other tasks for now, but I was hoping that
> someone may have some insights as to what might be going wrong here,
> or at least some pointers as to what to try next.  It would be awfully
> helpful if the error message actually said what was wrong and there
> were a way to get more verbose/debugging output from svnsync and
> svnrdump.

E210008 is SVN_ERR_RA_SVN_EDIT_ABORTED.  Not sure how best to debug
that, the cleartext across the tunnel would be interesting but using
some sort on non-encrypting tunnel might make the problem go away.

It's possible that svnserve logging will show something of use.  I don't
know of any simple way to enable logging over svn+ssh but you can force
it as follows:

 - create a script on the server containing:

  #!/bin/sh
  /path/to/svnserve --log-file /path/to/log-file -t

 - cause svnrdump to invoke the script instead of svnserve:

  svnrdump dump --incremental -r511 \
   svn+ssh://server/some/svn/repos \
   --config-option config:tunnels:foo='ssh -q scmadm@somehost /path/to/script'

(The hostname in the URL is a placeholder, the tunnel defines which
server to use.)

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*


Subversion Exception! - wc_db.c line 8713 assertion failed

2014-09-18 Thread Justin Hu - 胡恩杰
--- 
Subversion Exception! 
--- 
Subversion encountered a serious problem. 
Please take the time to report this on the Subversion mailing list 
with as much information as possible about what 
you were trying to do. 
But please first search the mailing list archives for the error message 
to avoid reporting the same problem repeatedly. 
You can find the mailing list archives at 
http://subversion.apache.org/mailing-lists.html 

Subversion reported the following 
(you can copy the content of this dialog 
to the clipboard using Ctrl-C): 

In file 
'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db.c'
 
line 8713: assertion failed (svn_dirent_is_absolute(local_abspath)) 
--- 
确定 
--- 


OS: Win7 x64,  8GB RAM, Using TSVN to access code on a local disk partition 
which is mirroring to a network driver on VM's openSUSE 13.1 SAMBA service.
TortoiseSVN 1.8.7, Build 25475 - 64 Bit , 2014/05/05 20:52:12 
Subversion 1.8.9, -release 
apr 1.5.1 
apr-util 1.5.3 
serf 1.3.5 
OpenSSL 1.0.1g 7 Apr 2014 
zlib 1.2.8

The issue happened when I double clicked a .c file listed in svn log window for 
remote HTTP svn server. Before this operation , I terminaled a long-time 
no-response TSVN window. It seems related to Windows temp file.


Sincerely
from Justin Hu