Re: Subversion 1.6

[Quinn Taylor]

On Mar 30, 2009, at 2:09 PM, Alberto Ganesh Barbati wrote:

On 30 Mar, 04:06, Quinn Taylor <quinntay...@mac.com> 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.

I wasn't trying to start a dispute about it, but be aware that many people internal to Apple often refer to "built-in" tools. Of course this is meant to refer to the stock tools, the default, the ones that ship with the system, the ones that can affect the entire system if modified, ones that require admin access to change. I apologize if this caused any confusion, but I didn't mean they were built into anything in particular, which is why I specifically listed the locations where they are installed. (As a note, I can't find anywhere on that link that backs up your claim. Midway down the page, it states that Xcode 1.5+ has support for Subversion built-in, but nothing about which version of Xcode. That article was last update at the end of 2005, right when SVN 1.3 was released, which is why the instructions detail installing SVN 1.2.3.)

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.

No offense, but that's a flawed premise. Compatibility of one application does not imply compatibility of all applications. I know the Subversion team takes great pains to ensure maximum compatibility, but sometimes bug fixes can break expected behavior, and my experience is that allowing one's software to knowingly operate in untested situations is dangerous. Xcode has a vastly larger development and test team than does Versions, and it's an entirely different beast. If the Versions devs were to state that their app is designed to work with SVN 1.6.x and provide instructions to upgrade, then one can make the case that it should be safe. Given the recurrent nature of several other feature requests and bug reports, I'm sure the devs are more occupied with things that will are more important to a greater number of users. I made no assumptions (or insults) about your skill or experience. It's true that Subversion isn't designed for "dumb end users" — it is generally assumed that people who are dealing with Subversion have a higher level of expertise. However, many of the questions on this forum indicate that many Versions users are still relative novices when it comes to the ins and outs of Subversion. (Heck, I'm an experienced programmer, and I still do pretty much all my work in trunk! I've been waiting to deal with branching and merging until I can move all my development to 1.5. For personal projects, I simply haven't had the need to branch.)

Versions already checks the version of the command-line binaries in /
usr/bin for compatibility to help minimize conflicts and be a good

be nice if there were an easier process for end users to update the

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.

citizen, for which the devs are to be commended. I agree that it would 1.4.x and 1.5.x libraries bundled inside Versions. It's not highest on

I don't need, nor request to update the libraries shipped with
Versions.

Okay, I understand that you would prefer linking to libraries in some location of your choosing to replacing the libraries bundled in Versions. However, if you want to support 2+ versions of SVN libraries, such an option would open a can of worms. Binary compatibility and linker errors are some of my least favorite things, and exposing options to change the paths to linked libraries in Preferences is asking from trouble from novice users, IMHO. Remember that Versions is geared more towards novices than experts, and I'm thinking from the noob point of view.

Perhaps if the preference to point to a custom library location were

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. :-)

unexposed in the UI and had to be set in Terminal using the `defaults`

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

Cheers,
 - Quinn

A fair opinion, and you're entitled to it. My opinion is that some of the best parts of polished Mac apps are restraint and minimalism in the UI. That is to say, maximizing available functionality while minimizing clutter. Creating UI for 1% of the target audience to modify something that will likely cause the 99% to shoot themselves in the foot is something I'd consider a mistake. If you're selling your application, alienating novice users that are most likely to recommend your app can be suicide. Apple has its share of "hidden" defaults settings, as do many other apps. The common thread between them is that the average user generally doesn't care about them, and shouldn't have to. The moment something is publicly exposed (especially in UI) there comes an implicit expectation that it will be supported. Taking a cue from how this problem is handled for Xcode, I think that having documentation on how to effect such a change would be sufficient, and probably much better than confusing users. In the end, I think the real solution is to have more frequent releases that use the most up-to-date libraries. :-) I'm optimistic that a pending release will make this problem a non-issue. Hope that me playing devil's advocate hasn't tried anyone's patience unduly, and I apologize if any offense was given.

smime.p7s
Description: S/MIME cryptographic signature