NOTE: SVN 1.7 is fully "out of support" - it's really time to upgrade, especially if you're running on RHEL 7.2. You probably should pick up some new SVN binaries (e.g. 1.9), perhaps at [url]https://www.wandisco.com/subversion/download[/url] .
What account are you running that "svn co" command as? "svnadm"? If so, why not just use "file:///home/svnadm/comptelsvn" as the URL?
If not, then what is in your current working directory when you go to run the "svn co" command? I'm assuming that there is no "comptelsvn" directory in prior existence. So that would mean that the "svn 1.7.14" version is not happy with the installed SQL version (well, actually it's the SQL that's not liking the command/query that SVN is using to create an SQL database as part of the svn working copy creation). Again, some inconsistency with SVN vs. SQLite?
Note: SVN 1.6 does not have an embedded SQLite DB in the working copy so such an issue can not occur.
Thanks Doug for your reply. svn co is used with application user and not the svnadm. There is no working directory as i am trying to create a working directory by downloading from svn.
To resolve this SQLite Db error what should we do?
Should we upgrade the client to 1.9 as you mentioned where this problem will not occur. please suggest.
Thanks once again for your response.
Honestly, I'd install the SVN 1.9 package and dependencies and see if that resolves the issue. Note that you can use an SVN 1.9 client against any other SVN server version. Of course, the way that you're using it - same box - then it would be running against itself so no worries there.
NOTE: SVN 1.9 has the same dependency on a working SQLite as does SVN 1.7. But the installation of SVN 1.9 may trigger proper dependency installation thereby fixing the issue.
Is there any reason that you can't upgrade your SQLite version?
May be its a stupid question but i dont know where the SQLite is installed. Is it installed seperately than SVNClient.
I will try and install version 1.9 as suggested, however i am happy to upgrade my SQLite if i know where to check for this.
By the way i am running this client on application server and application server uses SQLDatabase Oracle 12.
Rajan: Not a stupid question. I believe that the SQLite dependency is actually compiled into SVN itself... but I'm not 100% sure.
Knowing that you've got SQLDatabase Oracle 12 on the server is definitely giving me pause... Do you know if the installation of that product changes the LD_LIBRARY_PATH ? Could you check to see whether it is defined in your shell's context and what value it might have?
The settings for the SQLDatabase is correct as it reflects the same as in our other servers so i really doubt it can be the reason or has any connection with the problem stated.
however, i will now install the 1.9 version and hope dependencies is sorted. by the way we can also upgrade our SVN server. In your opinion would that help? if yes, will that have no impact on our other connected servers where 1.6x subversion is being used. Whats's your view.
I'm not concerned about the settings for SQLDatabase - but more about how they might have changed a "system global" behavior. The LD_LIBRARY_PATH environment variable has been used, for better or worse, to work-around some subtle binary-to-shared-library dependency issues. If that environment variable has been modified globally then it is possible that it could, in fact, cause issues like what you're seeing. If that is the case, then writing a wrapper-script to the "svn" command could be one possible work-around. You could try this by running the "svn co" as:
LD_LIBRARY_PATH="" svn co ...
That temporarily, for that single command, empties out that environment variable.
As far as upgrading your SVN Server, given the command you specified above, using the loop-back network address, I had assumed that you were running on the server. If you install Subversion there then it will not just upgrade the client but the server also. You're right to ask about this. If you're in production then an upgrade should be done carefully, with a full backup done beforehand.
That said, Subversion 1.9 server has deep compatibility with prior version of clients (as Subversion 1.9 client has deep compatibility with prior versions of servers). It is incredibly rare for a Subversion server upgrade to cause issues for Subversion clients. That's not to say that they don't happen - they do. Hence the full backup.
Empting LD_LIBRARY_PATH worked. i am able to perform checkout. however, could you explain this in more details how to solve this permanently.
All in all it worked.
After svn co, i am not able to upgrade the svn and below error is seen
$ /usr/bin/svn upgrade
svn: E155019: Can't upgrade '/IDC/Rajan/comptelsvn' as it is not a pre-1.7 working copy directory
svn: E150000: Missing default entry
Ok, great to learn that the issue is centered around LD_LIBRARY_PATH. As I said before, that makes sense because it ends up causing the Oracle SQLDatabase to interpret the SQLite command - and it does not like that syntax (which is, believe me, a best case scenario since it stopped things EARLY).
To better understand how to go about "fixing" the issue around LD_LIBRARY_PATH you need to understand what it does. Essentially, it says that the running process should get its shared libraries from that path BEFORE looking in the normal places that were built into the application (normally at "bind" time). This environment variable is incredibly powerful and, normally, it should be empty. However, some vendors use it to enable more flexible installation of their pre-built software.
An example might help. Lets say that Vendor A has software that normally installs into "/usr/bin" and those binaries refer to shared libraries that normally install into "/lib64". Unfortunately, Customer X has IT Security rules that prohibit their modifying either "/usr/bin" or "/lib64". So they install to "/application/vendorA/usr/bin" and "/application/vendorA/lib64". But now their binaries don't work since they're built with references to "/lib64/vendoralib.so" and that shared library is now in "/application/lib64/vendoralib.so". So what do they do? They change "LD_LIBRARY_PATH" to include the new path "/application/vendorA/lib64" and now it runs.
In your case the problem is that you have a subset of commands that require that LD_LIBRARY_PATH be set [U]and at the same time[/U] a different set of commands that require that LD_LIBRARY_PATH be free of that reference.
Honestly, there's no perfect solution.
As long as you are using just the "svn" command then you could create a script-front-end to strip the environment of the LD_LIBRARY_PATH and then run the real "svn" command. Put that wrapper script in a bin directory that is in your PATH before wherever the real "svn" command is and it just works. Of course, there are other ways to get to SVN - Python bindings, Perl bindings, etc. and each of those will need some other hacky solution.
The alternative is to write a wrapper script for all of the Oracle commands that sets the LD_LIBRARY_PATH and then use those scripts and CLEAR out the LD_LIBRARY_PATH for all other contexts. Honestly, while this is more work, it's the "right thing" to do. In general, it is [U]extremely unfriendly[/U] to set LD_LIBRARY_PATH due to the mysterious downstream issues it causes. As you've found out the hard way.
As for your "svn upgrade" question, the "svn upgrade" command is used to upgrade a working copy from an "old" format to the "current" format. It does [U]not[/U] upgrade the installed version of Subversion. To do that you will need to track down an new set of packaged binaries and install them. If you have trouble with the URL I provided above please let me know.