[wplug] SOLVED: SVN upgrade -> mismatched RA version

[Shane Liesegang]

If anybody cares...

My local subversion install failed to compile some of its libraries because
it was missing dependencies. But because it reported this as a warning
instead of an error, I didn't notice it. (Arguably, since those libraries
are crucial for the app to actually do anything, perhaps it should have been
an error.) When my local binary couldn't find its libraries, it proceeded
down the library path and found the server install, which was producing the
version mismatch.

Fixed the dependencies, and all was well!


On 2/16/07, Shane Liesegang <shane at shaneliesegang.com> wrote:
>
> OK, upon further inspection...
>
> SVN is compiled and installed local to my user account. But when I go to
> run it, it's apparently still looking at the global libraries, which are a
> different version. I've tried setting LD_LIBRARY_PATH, but it still gives me
> the same error.
>
> I want to use ldd to see which libraries it's actually trying to load, but
> it'll only let me do that on the vanilla executable. That is, I can "ldd
> ~/bin/svn" and get it's libraries (which all point to the proper versions),
> but the problem arises when I try to do something with svn, like update or
> commit. Heck, even "svn help" throws an error. But I can't find a way to
> make ldd run on a program with command line arguments; it treats anything
> space separated as a different executable it's supposed to test. My guess is
> that SVN doesn't actually load the libraries until it tries to do something,
> and at that point it's looking in the wrong place.
>
> Oh, such convoluted issues. Anybody have any thoughts? This is making me
> sad.
>
>
>
> On 2/16/07, Shane Liesegang <shane at shaneliesegang.com> wrote:
> >
> > Hmmm. I figured I might have to match the repository, but I'm getting
> > the error without ever even trying to connect to anything (svn help). Which
> > leads me to think there's some kind of program config problem I need to deal
> > with before even trying to connect to a repo.
> >
> > Curiouser and curiouser...
> >
> >
> > On 2/16/07, Weber, Lawrence A < laweber at switch.com> wrote:
> > >
> > >  A few months ago, I tried to convert our Version Control to SVN.  In
> > > the middle of my eval tests, SVN was upgraded resulting in my TortoiseSVN
> > > client being a newer than my command line tools.  I used the command line
> > > tools to create my repositories but planned to provide the users with
> > > TortoiseSVN.  When I used the newer TortoiseSVN it changed the repository
> > > format so that the command line client could no longer access files.  Same
> > > kind of errors you are seeing.  This feature caused so much trouble that I
> > > was forced to ClearCase, yuck.
> > >
> > > Looks like you need to get the older client.  One that matches your
> > > repository.
> > >
> > >  ------------------------------
> > > *From:* wplug-bounces+laweber=switch.com at wplug.org [mailto:
> > > wplug-bounces+laweber=switch.com at wplug.org] *On Behalf Of *Shane
> > > Liesegang
> > > *Sent:* Friday, February 16, 2007 2:04 PM
> > > *To:* General user list
> > > *Subject:* [wplug] SVN upgrade -> mismatched RA version
> > >
> > > I'm on a shared host that uses version 1.3.2 of Subversion, and I
> > > recently compiled and installed a local copy of version 1.4.3.
> > >
> > > Now when I try to run any svn commands, I get  a message about
> > > mismatched RA versions.
> > >
> > > $ svn help
> > > svn: Mismatched RA version for 'dav': found 1.4.3, expected 1.3.2
> > > $ svn co http://{my_repo}
> > > svn: Mismatched RA version for 'http': found 1.4.3, expected 1.3.2
> > >
> > >
> > > Some googling showed that these errors happen when there's bits of old
> > > installs leftover from an upgrade. Of course, in my case, the old version is
> > > still on the system. I get these even if I directly run the new binary (as
> > > opposed to trusting my $PATH).
> > >
> > > Has anybody dealt with this before? Any words of advice on how to
> > > proceed? I'm afraid I hosed SVN. :-(
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.wplug.org/pipermail/wplug/attachments/20070217/66ec1690/attachment.html