On 30 Mar, 04:06, Quinn Taylor <[email protected]> wrote: > That said, the "special" thing about the built-in SVN libraries is > that they are version 1.4.4 only.
In your valiant effor to clarify things, this statement is very imprecise. It's true that MacOSX ships with the 1.4.4 libraries, but those libraries are not "built-in" into anything and nothing prevents the user to upgrade them. In fact the XCode SDK states explicitly (see http://developer.apple.com/tools/subversionxcode.html) that it was designed to work with 1.5.x and you can find on the developer forums the procedure to upgrade. > 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. If it's safe for XCode, why wouldn't it be safe for Versions? Really I don't get it. We are not talking of a tool for dumb end users. I am a programmer with 20+ years of experience, I know that if I upgrade there is a risk of incompatibility. I won't blame the programmers of Versions if it happen. But I do blame the programmers of Versions if they don't let me try simply because they are afraid of user complaints. Especially since it is a feature that de facto is already implemented! Versions is shipped with two bundles, namely SA146.bundle and SA154.bundle. I don't know the details, but I'm pretty sure that if I put symbolic links into one of those bundles, everything will work just nice. > 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. I don't need, nor request to update the libraries shipped with Versions. > 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. :-) I think that providing an "hidden" feature is kind of stupid. Versions already warns you about possible incompatibility between 1.4.6 and 1.5.4. Just add another warning. If the user wants to shoot himself on the foot, just let him. Just my opinion, Ganesh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/versions?hl=en -~----------~----~----~----~------~----~------~--~---
