-----Original Message-----
From: Bob Cunningham [mailto:bcunningham@sandel.com]
Sent: Friday, August 03, 2007 4:48 PM
To: users@tortoisesvn.tigris.org
Subject: Determining TrotoiseSVN version from a script.
Hi,
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 required).
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?
Hi Bob: I don't understand what you mean by "adhere to the same version of
Subversion". We use various versions of TSVN, they all talk to the same
server, and everything works correctly.
If we don't want people changing things in the source repository, we don't
give them write access.
If we want a specific revision of code, we ask for it when we check out.
The client we use makes no difference. SVN gives us the code every time.
We've had more than one challenge to the integrity of our code base, and SVN
has not yet let us down. TSVN in particular has made it very easy for us to
review code and investigate history.
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.
It sounds like you have an administrative need to document the versions of
tools that you use with a particular revision of your repository. Have you
considered commiting the TSVN or Cygwin client files as part of your
repository? I might be misunderstanding your requirement though.
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).
It might help if you could explain more about what you are trying to do.
TSVN is a GUI application, to be sure, and if you want a GUI, I think it's
quite nice. I've never heard of someone automating tasks with it. I don't
consider that a negative.
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.
After reading this last paragraph and thinking a bit more, I wonder if your
issue is needing to manipulate the same working copy using two different SVN
clients on the same machine -- one for the automated task and TSVN for human
use. Occasionally, working copy formats might change, so I could see that
NewClient might update a WC in ways that OldClient might not be able to deal
with.
Is that the problem you want to solve? Erik
Help?
-BobC
Received on Fri Aug 3 23:49:06 2007