Re: Subversion 1.6

[Quinn Taylor]

On Mar 29, 2009, at 3:17 PM, Alberto Ganesh Barbati wrote:

On 29 Mar, 13:18, Koen Bok <k...@madebysofa.com> wrote:

On Mar 28, 9:58 pm, TheDO <webmas...@thedigitalorchard.ca> wrote:


around the bundling of the subversion client into Versions.app, and
not supporting external subversion clients. I know this has been

others) why Versions is built this way? Is there something special
about the built-in subversion client?

It's great to hear 1.6 support is coming. I want to put out my concern discussed before, but can someone in the know remind me (and possibly

Hey TheDO,

Generally the best way to build apps around other apps is to include
their functionality with programming libraries they provide. That way
you can access all the functions right in the programming language
which has the least overhead and is usually less error prone.

Another way to build an app like Versions would be communicating with
the command line program. That means that you have to "manually" send
text commands to the app and parse it's output (this is called
piping). This way it would be possible to replace the binary that
Versions communicates with, but as we would really rely on the input
and output it will break easily. Plus, we could never get the app as
fast as it is now.

Hope that explains it :-)

You are missing the point. No-one has ever thought of using the
command line, given that Subversions ships with a very nice set of
dynamic libraries. The point of TheDO was that Version is currently
shipped with two sets of such dynamic libraries, one for v1.4.6 and
one for v1.5.4. You can select the set you prefer and Versions will

usr/lib Subversion v1.5.6 so that I can happily use it in XCode. But
Version is stuck with v1.5.4.

I believe it is perfectly feasible to have a preference in Version to
make it use the libraries in /usr/lib instead of the one shipped with
Versions. If we had that, I could just install the v1.6 libraries in /
usr/lib and we wouldn't need to wait for the next update of Versions
to use them.

Just my opinion,

Ganesh

use that one. That's nice. However, on my machine I have installed in /

 - Quinn

This is a valid question about how Versions provides SVN functionality, but I think the way in which it was posed caused some confusion, as have some of the responses. For anyone confused about how Versions and other SVN clients interoperate, I hope I can clarify a bit. Leopard ships with version 1.4.4 of the full complement of Subversion tools. The "binaries" (the tools you'd run from Terminal) are installed in /usr/bin, and the libraries (code which third-party applications—either command-line or GUI—can link against to accomplish SVN tasks by using a supported API) are installed in /usr/lib. In addition, there are bindings for other programming languages, including Perl, Python, and Ruby in various locations, modules used for hosting SVN repositories via Apache 2, documentation, and a few other things. Most of these components are inconsequential for end users. However, an important distinction is that a Subversion "client" is a program that interacts with a Subversion repository server. This is generally done through the aforementioned libraries. Thus, SVN clients include Versions, Xcode, Eclipse (via plugins), svnX, and any other program that does checkouts, commits, etc. Thus, Versions bundles SVN libraries, but not any SVN "clients" in the strictest sense. That said, the "special" thing about the built-in SVN libraries is that they are version 1.4.4 only. Since Versions is designed to support 1.5.x as well, and can't count on users having 1.5.x installed, the logical choice is to bundle the necessary library internally. By the same token, for someone like Ganesh who has replaced the built-in 1.4.4 tools with the 1.5.6 tools, Versions also shouldn't count on users having 1.4.4 installed, so it's also bundled internally. Similarly, although using 1.6.x should "just work", if anything in Versions were incompatible with or buggy under a newer release of SVN, it wouldn't be "safe" for them to allows users to dynamically link to whatever is installed in /usr/lib, or /opt/ subversion, or wherever. Versions already checks the version of the command-line binaries in / usr/bin for compatibility to help minimize conflicts and be a good citizen, for which the devs are to be commended. I agree that it would be nice if there were an easier process for end users to update the 1.4.x and 1.5.x libraries bundled inside Versions. It's not highest on my priority list, since the minor point releases generally fix fairly minor bugs and don't introduce any new backwards-incompatible functionality. There are many other points of usability and polish on which I place higher value, although I'll be glad to have a newer bundled SVN as well. Perhaps if the preference to point to a custom library location were unexposed in the UI and had to be set in Terminal using the `defaults` command, it would be self-evident that if you change it, you get what you get, and don't blame the developers. Even so, I think it would be difficult to make it work in all cases, since the devs wouldn't be able to link against every possible library at build time, and you wouldn't want them to since it could have an adverse effect on binary size and load time. I'll trust the devs to decide whether such an approach would even work, since they know their code. :-)

smime.p7s
Description: S/MIME cryptographic signature