[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Determining TrotoiseSVN version from a script.

From: Bob Cunningham <bcunningham_at_sandel.com>
Date: 2007-08-03 22:48:02 CEST

I'm automating key portions of an error-prone manual process that
presently uses TortoiseSVN. The script will use the Cygwin command-line
svn client, and is intended to run autonomously (no human interaction
I have one problem: If the user updates TortoiseSVN on the local system
without updating the command-line client, there is a good chance that my
script will fail, and/or corrupt the state of local checkouts. (This
has happened to us before: We presently block all TortoiseSVN update
checks at our firewall and prevent Cygwin updates to svn, but that won't
stop a well-intentioned user armed with a browser.)
I need a way for my script to determine that the command-line client and
the TortoiseSVN installation both adhere to the same version of
Subversion. How can a script determine the version of TortoiseSVN that
is currently installed?
Something like a "/version" switch for TortoiseProc would do nicely, but
only if it outputs text to stdout instead of invoking the About box.
Alternatively, it would be great if TortoiseSVN simply included a
compatible command-line client (both get updated together).
Better yet (from an automation perspective) would be a mode where
TortoiseSVN would output text for the equivalent svn command line.
In general, this limitation is a strong reason to avoid native GUI
implementations of any command-line tools, unless the GUI version is
tightly bound to a specific instance of the command-line version. GUI
wrappers, though often slightly less functional, and sometimes slower,
can't possibly have this problem.
This is the *only* significant negative I've come across with
TortoiseSVN. However, if no solution is found, the inability to
automatically enforce a version match between TortoiseSVN and the
command-line client will be enough to discourage use of TortoiseSVN in
our development environment, and seek another GUI client (perhaps
RapidSVN, when it ships).
Our entire Quality system is based on automating repetitive tasks, and
from this perspective (and only this perspective), TortoiseSVN is a
thorn in our side. Other than this one important issue, TortoiseSVN has
proven to be one of our most useful and reliable tools.
There are other oft-repeated processes where simple automation would
prove useful, the main one being to force periodic updates to local
checkouts of key directories. I know of no way to set up a Scheduled
Tasks item to do this using TortoiseSVN. Yet the result must be 100%
compatible with the locally installed instance of TortoiseSVN.
Received on Fri Aug 3 22:46:18 2007

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.