svn: E200030 Issue while checking out SVN

Hi team,  I am facing a problem with SVN access with the new client installed. I am using RedHat 7.2 with SVN client version   $ svn --version svn, version 1.7.14  While checking out my svn working copy i am getting below error:  $ svn co svn+ssh://svnadm@127.0.0.1/home/svnadm/comptelsvn  svn: E200030: near "OLD": syntax error, executing statement 'CREATE TRIGGER nodes_insert_trigger AFTER INSERT ON nodes WHEN NEW.checksum IS NOT NULL BEGIN UPDATE pristine SET refcount = refcount + 1 WHERE checksum = NEW.checksum; END; CREATE TRIGGER nodes_delete_trigger AFTER DELETE ON nodes WHEN OLD.checksum IS NOT NULL BEGIN UPDATE pristine SET refcount = refcount - 1 WHERE checksum = OLD.checksum; END; CREATE TRIGGER nodes_update_checksum_trigger AFTER UPDATE OF checksum ON nodes WHEN NEW.checksum IS NOT OLD.checksum BEGIN UPDATE pristine SET refcount = refcount + 1 WHERE checksum = NEW.checksum; UPDATE pristine SET refcount = refcount - 1 WHERE checksum = OLD.checksum; END; '  the svn is working from other REDHAT versions i.e 6 and above with client veriosn 1.6.x.  Is this problem specific to the new version of the client or i am looking at totally different.  Your help is much appreciated.  Thanks, Rajan 

Last updated 6 years ago

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 https://www.wandisco.com/subversion/download .  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.  Thanks, Rajan 

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 and at the same time 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 extremely unfriendly 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 not 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.