Setting path to binary in preferences window is not consistent

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install svn-client via fink
2. Set path to svn binaries to /sw/bin in svnx
3. load a working copy using svnx

What is the expected output? What do you see instead?
In the preferences window, the correct version number _is_ actually shown
(it shows 1.6.2 this is correct), but opening the working copy (double
click in the cmd+shift+C window) in svnx will produce the typical svn error

"This client is too old to work with working copy '.'.  You need
to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details."

However, running
 /sw/bin/svn update
in the terminal does work correctly on the working copy

What version of the product are you using? On what operating system?
1.1b1

Please provide any additional information below.
I have now used the "official" package mentioned in the readme, which does
work too, though now setting a different path to svn library (eg. /usr/bin
wich has version 1.4.4 instead of /usr/local/bin wich now shows as 1.6.2 as
expected) will not produce the incompatible working copy error when opening
the working copy but it *will* when pressing the update button afterwards.
This again indicates that this preference setting is not functioning as
intended.

Original issue reported on code.google.com by e.wat...@gmail.com on 26 May 2009 at 11:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Do you have 'Call Subversion libraries directly' on or off?  It should probably 
be off in your case.
Otherwise stick with /opt/subversion/bin.  (BTW The path is that of the tool 
not the libraries.)

With that option switched on svnX uses direct lib calls for some functions 
(e.g. status) and the svn tool
for others (e.g. update).  With it off svnX only uses the svn tool.  The 
libraries must be located in 
/opt/subversion/lib (unless you've changed the links in 
svnX.app/Contents/Frameworks, but that's untested).

It appears that, initially, you had an older copy of Subversion's libs in 
/opt/subversion (svn 1.5.4 produces
wording as above, 1.4.x doesn't).  Then, after installing 1.6.2 in 
/opt/subversion (not /usr/local) you created
the opposite problem by trying to use svn 1.4.4 from /usr/bin.

I've decided that the direct libs & the tool need to have a closer version 
match to be (really) compatible.
I think I need to refine the tests for enabling/disabling the direct libs 
because the 1.6.x libs claim to be
compatible with 1.4.4 but this appears to be only at the API level & not at the 
usage level.

BTW Apparently the official (CollabNet) 1.6.2 installer does NOT install in 
/usr/local/bin,
so I don't know what version you are actually using/getting.

Original comment by chris...@gmail.com on 27 May 2009 at 3:39

[GoogleCodeExporter]

Yes, the "Call Subversion libraries directly" is/was checked; and no, it should 
*have
been* off, but now it doesn't really matter. Maybe that checkbox should be  
disabled
if the versions don't match? A 2nd field like the binary one to specify the 
library
location might work too (complete with the version check thingy, which rocks 
btw.)

Oh, and maybe add "/opt/subversion/bin" to the tooltip of the "path to svn 
binaries
folder" input box.

The stuff under "Please provide any additional information below." header was 
just
from me trying to find out what happened, and I thought you might be able to 
use it,
the install in /usr/bin seems to be the one from xcode wich is incredibly old, 
for me
it proved that *some* methods used a different location of svn

> BTW Apparently the official (CollabNet) 1.6.2 installer does NOT install in
/usr/local/bin,
> so I don't know what version you are actually using/getting.
You are right. A (long...) time ago I created symlinks to /opt/subversion/bin/* 
in
/usr/local/bin so I could use it in terminal without adding yet-another-path to 
PATH;
and I totally forgot. So the actual install location is in fact /opt/subversion 

Original comment by e.wat...@gmail.com on 27 May 2009 at 11:45

[GoogleCodeExporter]

The 'Call Subversion libraries directly' IS disabled (& switched off) if the 
tool & lib versions don't "match".
The problem is the definition of "match".
Until now the "match" was the same code `svn` uses itself.
[However, I think that it's fundamentally wrong as it can result in svn v1.4 
silently using v1.6 libs
 as well as reporting that it is v1.6!]

So I've changed the test to be an exact match of version numbers between the 
tool & libs.
Fixed in r109.

> A 2nd field like the binary one to specify the library location might work too

Ay, there's the rub.  Unfortunately the libraries must be in place before the 
app is launched.
The only alternative is to manually load them which would then require 
in-directing all calls
through some kind of stubs which would mean writing & maintaining them for all 
svn functions used.
Plus if the setting could be changed svnX would need to free all svn data 
structures, close all
connections & unload the old libs before reloading the new ones, reopening any 
connections &
recreating any data structures.
I don't know if it's worth the effort.

Original comment by chris...@gmail.com on 27 May 2009 at 4:24

• Changed state: Fixed

[GoogleCodeExporter]

I guess I am having the same problem.

I am the one who also want the '2nd field.'

I need the MacPort version of svn installed under /opt/local/bin and the 
libraries
are in /opt/local/lib.

But although having set the binary location to /opt/local/bin, the libraries 
are read
from /usr/lib or somewhere else.

And I want the auto refresh, so I am making links of bin, lib and include of
/opt/local to /opt/subversion and having the binary location set to 
/opt/subversion/bin.

This seemed to work, but for the recent build or two, I am having the 'Call
subversion libraries directly' option dimmed (and unchecked.) 
Is this becuase svnx cannot find the library to link?

Original comment by kim.take...@gmail.com on 30 May 2009 at 3:36

[GoogleCodeExporter]

I don't understand your problem.
'Auto refresh' DOES NOT require 'call directly'.
AND it should be possible to use different libs by changing the symbolic links
in svnX.app/Contents/Frameworks.  Have you tried this?

If the 'Call Subversion libraries directly' preference is disabled it means the 
libs
are unavailable or have a different version to the svn tool.
Un-comment the last dprintf statement in SvnInitialize in SvnInterface.m to see.

Unless there's actually a bug can we please move this discussion
to (the new) http://groups.google.com/group/svnx.

Original comment by chris...@gmail.com on 30 May 2009 at 4:28

[GoogleCodeExporter]

> Unfortunately the libraries must be in place before the app is launched [...]
I know it's not quite apple-like but you could do something like "changing this
setting requires a restart of svnx" and then you /just/ have to load the 
specified
library (or try to) to check the version. No other wrappers, since on the next 
start
they will be loaded anyways.

I'm still not sure if it's worth the effort but that's an option I see. (I'd do 
a
patch myself, but I'm not really comfortable with objective c... yet)

Original comment by e.wat...@gmail.com on 30 May 2009 at 4:56

[GoogleCodeExporter]

> I know it's not quite apple-like but you could do something like "changing 
this
> setting requires a restart of svnx" and then you /just/ have to load the 
specified
> library (or try to) to check the version. No other wrappers, since on the 
next start
> they will be loaded anyways.

And exactly how do I get the app to do this before the system dynamically links 
it to all the libraries?
[Which it does before executing any code in the app - obviously.]

The only reasonable way I see of doing it is as I've outlined above.
[Which is effectively writing my own dynamic linker.]

Please move any further discussion of this
to (the new) http://groups.google.com/group/svnx.

Original comment by chris...@gmail.com on 1 Jun 2009 at 11:32