What is UDS in subversion? (Strange issue in SCC SVN client PushOk)
Hi We are using a MSSCCI to SVN client (PushOk) which in the version 1.7.13 and with our project does strange things. When opening our IDE SccProjectOpen() is called on the MSSCCI interface. I do not exactly know what is done on the SVN level, but with the SccProjectOpen() call, outdated local copy files get somehow updated (which they should not). Strangly only the base file and the meta (.svn) data get updated but the real working copy file remains unchanged, rendering this file locally modified. TortoiseSVN (1.7.13-svn1.7.10), used for verification shows outdated before and uptodate but locally modified afterwards. The only indication I have from PushOk is that it is printing Received: UDSsome number/a/sub/path/to/our/project/root/path/aFile.ext Received: UDSsome number/a/sub/path/to/our/project/root/path/anotherFile.ext : in its status box. Does that look familiar to someone? Could that be SVN messages from callbacks that are shown here? Instead of your projects root folder always UDSsome number is printed where as the some number does NOT change for one SccProjectOpen() call but does change for a next call. Why is the projects root folder replaced? I searched subversion and uds in the internet and found uds_path in some hits. Generally it looked like a session id to me in the first place. What is this UDSsome number? What is a uds_path? What stands uds for? I know I should ask the PushOk folks about what they are doing in their MSSCCI-SVN provider. But communication is basically non-existent (no answers for a looong time). I am only trying to get hints to understand what is happening and would appreciate any clue. Regards Roman
Re: What is UDS in subversion? (Strange issue in SCC SVN client PushOk)
On 29.01.2014 09:10, Roman Kellner wrote: Hi We are using a MSSCCI to SVN client (PushOk) which in the version 1.7.13 and with our project does strange things. When opening our IDE SccProjectOpen() is called on the MSSCCI interface. I do not exactly know what is done on the SVN level, but with the SccProjectOpen() call, outdated local copy files get somehow updated (which they should not). Strangly only the base file and the meta (.svn) data get updated but the real working copy file remains unchanged, rendering this file locally modified. TortoiseSVN (1.7.13-svn1.7.10), used for verification shows outdated before and uptodate but locally modified afterwards. The only indication I have from PushOk is that it is printing Received: UDSsome number/a/sub/path/to/our/project/root/path/aFile.ext Received: UDSsome number/a/sub/path/to/our/project/root/path/anotherFile.ext : in its status box. Does that look familiar to someone? Nope ... Could that be SVN messages from callbacks that are shown here? Sure, could be; but Subversion doesn't insert the UDS stuff. That part must be coming from PushOK. Instead of your projects root folder always UDSsome number is printed where as the some number does NOT change for one SccProjectOpen() call but does change for a next call. Why is the projects root folder replaced? I'm just guessing, but it looks like they use that as a session identifier; and the project root folder is not being replaced; this looks like a session ID plus relative path /within/ the working copy. I searched subversion and uds in the internet and found uds_path in some hits. Generally it looked like a session id to me in the first place. What is this UDSsome number? What is a uds_path? What stands uds for? It has nothing whatsoever to do with Subvesion. Your guess about what it means is as good as mine ... I know I should ask the PushOk folks about what they are doing in their MSSCCI-SVN provider. But communication is basically non-existent (no answers for a looong time). [insert blurb here about not using proprietary tools] If you're not actually constrained to MSSCCI but can use VAPI instead, you could try using AnhkSVN. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: line 1801: assertion failed (SVN_IS_VALID_REVNUM(changed_rev)) [SEC=UNCLASSIFIED]
Levy, Gabriel (Contractor) gabriel.l...@dsto.defence.gov.au writes: I've upgraded from TortoiseSVN 1.7.3 (build 22386) using Subversion 1.7.2 to TortoiseSVN 1.8.4 which uses Subversion 1.8.5 Now I'm getting almost every time I try to checkout a project tree with externals in it, the following Exception/Assertion at random times: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.4\ext\subversion\subversion\libsvn_wc\wc_db.c' line 1801: assertion failed (SVN_IS_VALID_REVNUM(changed_rev)) That's the changed_rev parameter passed to svn_wc__db_base_add_file, which is only called from update_editor.c:close_file. The changed_rev value should have been extracted from the entry property in accumulate_last_change. What do your svn:externals look like, what format do they use? Are they within the same repository or to different repositories? Are they file or directory externals? I don't think file externals cause a call to svn_wc__db_base_add_file so it's either a directory external or the main working copy that is triggering the error. Which server version are you using? Which protocol? Which server/protocol for the externals? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Fwd: Re: SVN notify--post-commit---steps
Please provide the steps of the SVN notify for Linux/Ubuntu. Original Message Subject:Re: SVN notify--post-commit---steps Date: Wed, 29 Jan 2014 16:15:46 + From: Eric Johnson e...@tibco.com To: sushant stal...@anuvatech.com Use the mailing list, please. On Jan 28, 2014, at 7:48 PM, sushant stal...@anuvatech.com wrote: can you give me the steps On 01/28/2014 10:44 PM, Eric Johnson wrote: Can't give you an answer, but can suggest a way to diagnose what's going on. The shell execution environment for Subversion hook scripts is quite limited. If the script works from outside of Subversion, it may be that something that the script uses isn't available in the PATH that Subversion uses when it is executing its scripts. You might try putting in script commands (python, bash, ruby, perl, other?) that log to a file, so you can debug the execution when run by Subversion. Eric On 1/28/14, 2:01 AM, sushant wrote: Hello sir, please provide me the SVN notify hook script for post-commit I have made changed in post-commit file but mail is not coming but manually run the post-commit file from command line then It works. so requested to you please provide steps Ubuntu/Linux. Thanks Sushant Talele
Re: encountered error with subversion version 1.8.0
On 1/29/2014 8:21 PM, Austin Mico wrote: Hi, I have encountered error with subversion. The conf for apache is LocationMatch ^/repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthLDAPURL AuthUserFile /etc/httpd/conf/svnuser_local Limit GET PROPFIND OPTIONS REPORT PROPPATCH POST MKCOL MERGE PUT COPY DELETE MKACTIVITY CHECKOUT require user svnuser /Limit /LocationMatch I encountered error is httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:20 2014] [notice] child pid 2740 exit signal Aborted (6) httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:21 2014] [notice] child pid 2742 exit signal Aborted (6) My svn client is version 1.8.5. These are Apache errors, so the first question is what versions of HTTPD and Subversion are present on the server. The client version probably doesn't matter. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: encountered error with subversion version 1.8.0
The versions are Subversion 1.8.0 and Apache 2.2. Thanks for the quick reply. On Thu, Jan 30, 2014 at 12:37 PM, David Chapman dcchap...@acm.org wrote: On 1/29/2014 8:21 PM, Austin Mico wrote: Hi, I have encountered error with subversion. The conf for apache is LocationMatch ^/repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthLDAPURL AuthUserFile /etc/httpd/conf/svnuser_local Limit GET PROPFIND OPTIONS REPORT PROPPATCH POST MKCOL MERGE PUT COPY DELETE MKACTIVITY CHECKOUT require user svnuser /Limit /LocationMatch I encountered error is httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:20 2014] [notice] child pid 2740 exit signal Aborted (6) httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:21 2014] [notice] child pid 2742 exit signal Aborted (6) My svn client is version 1.8.5. These are Apache errors, so the first question is what versions of HTTPD and Subversion are present on the server. The client version probably doesn't matter. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: encountered error with subversion version 1.8.0
On 1/29/14, 8:21 PM, Austin Mico wrote: I have encountered error with subversion. The conf for apache is LocationMatch ^/repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthLDAPURL AuthUserFile /etc/httpd/conf/svnuser_local Limit GET PROPFIND OPTIONS REPORT PROPPATCH POST MKCOL MERGE PUT COPY DELETE MKACTIVITY CHECKOUT require user svnuser /Limit /LocationMatch I think this is being caused by your LocationMatch. Every request is going to think that the server is rooted at the path you're requesting. LocationMatch can be used but you have to be really careful about it and in your particular case I don't think you need it at all. I also don't understand why you're using a Limit block around the require directive. That block is missing the MOVE, LOCK and UNLOCK methods. Assuming that you don't have SVNAutoversioning on turned on somewhere else you can't really do anything useful with those being open to anonymous users (MOVE without auto-versioning requires a transaction/activity which would require a POST or MKACTIVITY in advance and LOCK/UNLOCK are not allowed for anonymous users). So I suspect you really just want all actions against the repository to require the user. So just removing the Limit blocks and put Require user svnuser directly inside the Location block. Not sure what the AuthLDAPURL is doing in there with not value either. With those three things I suspect that your configuration should look like this: Location /repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthUserFile /etc/httpd/conf/svnuser_local Require user svnuser /Location I encountered error is httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:20 2014] [notice] child pid 2740 exit signal Aborted (6) httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:21 2014] [notice] child pid 2742 exit signal Aborted (6) What were you doing when you got this error? Do you have the error from the client, it should be returning an error as well. Even if the above resolves your problem I'd be interested in the above so that we can improve the error message you're getting in the future. I'd also encourage you to upgrade the server to a newer version than 1.8.0, we've fixed some bugs in the meantime.
Re: encountered error with subversion version 1.8.0
It keeps prompting for the password and throws the error below afterwards. svn: E215004: Commit failed (details follow): svn: E215004: No more credentials or we tried too many times. Authentication failed On Thu, Jan 30, 2014 at 12:46 PM, Ben Reser b...@reser.org wrote: On 1/29/14, 8:21 PM, Austin Mico wrote: I have encountered error with subversion. The conf for apache is LocationMatch ^/repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthLDAPURL AuthUserFile /etc/httpd/conf/svnuser_local Limit GET PROPFIND OPTIONS REPORT PROPPATCH POST MKCOL MERGE PUT COPY DELETE MKACTIVITY CHECKOUT require user svnuser /Limit /LocationMatch I think this is being caused by your LocationMatch. Every request is going to think that the server is rooted at the path you're requesting. LocationMatch can be used but you have to be really careful about it and in your particular case I don't think you need it at all. I also don't understand why you're using a Limit block around the require directive. That block is missing the MOVE, LOCK and UNLOCK methods. Assuming that you don't have SVNAutoversioning on turned on somewhere else you can't really do anything useful with those being open to anonymous users (MOVE without auto-versioning requires a transaction/activity which would require a POST or MKACTIVITY in advance and LOCK/UNLOCK are not allowed for anonymous users). So I suspect you really just want all actions against the repository to require the user. So just removing the Limit blocks and put Require user svnuser directly inside the Location block. Not sure what the AuthLDAPURL is doing in there with not value either. With those three things I suspect that your configuration should look like this: Location /repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthUserFile /etc/httpd/conf/svnuser_local Require user svnuser /Location I encountered error is httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:20 2014] [notice] child pid 2740 exit signal Aborted (6) httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:21 2014] [notice] child pid 2742 exit signal Aborted (6) What were you doing when you got this error? Do you have the error from the client, it should be returning an error as well. Even if the above resolves your problem I'd be interested in the above so that we can improve the error message you're getting in the future. I'd also encourage you to upgrade the server to a newer version than 1.8.0, we've fixed some bugs in the meantime.
