Any reasons not to use TortoiseSVN/Subversion 1.5.0?

[mjdl]

I'm thinking about installing the latest released version of TortoiseSVN/Subversion, which is now 1.5

Descriptions of new/improved features can be found at http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html and at http://subversion.tigris.org/svn_1.5_releasenotes.html

But I'm worried that Slickedit's Subversion code directly parses and will depend on the format of the output of the client-side executables--I don't think that Slickedit uses the official Subversion client API and libraries--and thus requires the previous versions (1.4.x) of TortoiseSVN/Subversion.

Can anyone comment who knows what the situation is?

[Matthew]

A few versions back we got burned when SVN changed the format of the entries file, so we don't read that directly anymore as a "shortcut". In SlickEdit 2007 and later, the command line client is used for all operations. As long as the svn.exe commandline arguments (and the console output format) haven't changed, I don't see any problems. Looking over the SVN website, I don't see anything under their "breaking changes" section that affect console-based input/output.

I say give it a shot. (Easy for me to say, right?) At least there's a get-out-of-jail-free card in the form of a perl or python script that you can run to revert an upgraded working copy back to 1.4.x format.

Ironically, in the latest version of the Tools product, we moved away from the shell-and-scrape approach in favor of using the svn 1.4.6 libraries. It seemed to be the more stable approach. (And it is in fact much faster and more reliable than shell-and-scrape) However, there are binary incompatibilities between the 1.4.6 and 1.5.x libraries, so you can't update and older 1.4.6-based client by dropping in new DLLs. svn 1.5.0 went gold the same week we released Tools 2.0.2. Grrrr.

[mjdl]

Thanks for the detailed answer. I think for the moment I'll stick with 1.4.6--it meets my needs very well.

Two supplementary questions:

1) When SlickEdit "scrapes" the SVN command output, does it use the XML format output that the command-line tools provide for that purpose? (I haven't yet looked at the macro source, but with Slickedit's abundant XML support, that would be the way to go).

2) Two thumbs up for the idea of bundling the Subversion library binaries in the next version of the Slickedit package! Even if it was a major version behind the actual current Subversion, it would still be a big win to have a version control system integrated into the package, and it would play nicely with the user (they can ignore it) and future versions of the Subversion servers (they just deliver the down-level transactions required).

Add that to the todo list for Slickedit 14.0... it shoots, it scores!

[Matthew]

Moving to using the XML output format is not a bad idea, but I don't think we have any real motivation to change it. We'd probably only make that change if the console output had breaking changes and the XML output was guaranteed to not change as much.

I also don't think we'll move to using the SVN C APIs anytime soon. It's a little easier for us on the Tools product, as that is a single platform, and it's Windows. We tend to get bit pretty hard when trying to distribute 3rd party libraries on the *nix platforms, especially all those Linux flavors. From a support perspective, asking a user install the svn command line client is a lot easier for both parties than hunting down some cryptic missing export on a god-knows-what-kernel-version Linux machine.

[mjdl]

Yes, I have to agree with you on the multi-platform considerations, it's something that would bring in unnecessary complications.

As for the change to parsing the command-line XML output rather than the raw text output, well, the Subversion people apparently added that to cater to that purpose, to provide a predictable tagged output irrespective of the tool version (and to avoid encoding and localization issues too). Maybe it's worth looking into on an overall cost/benefit basis.

Anyway, thanks for the answer.