Bob Cunningham wrote:
> 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).
Use the official Subversion client for Windows. The cygwin svn client is
*not* supported by the Subversion team.
And more important: it doesn't use the same working copy format since it
simulates a Linux client - working copies are *not* compatible between
different OS.
> 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.)
Instead of doing very complicated blocks (which I'm sure took you more
than 5 minutes to configure), you could have saved yourself a lot of
work by simply *reading the manual*:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-admins-upgradecheck.html
(and yes, the same manual is shipped with TSVN: simply hit F1 in any of
its dialogs).
> 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?
A script can't do that. At least not without reading undocumented
registry entries and using a table to relate the TSVN versions with
Subversion library version it is linked against.
> 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.
TSVN is a GUI client. If you need a command line client which outputs to
stdout, use the official SVN client (*not* the cygwin one!).
The TSVN installer has the Subversion library version in its filename.
> 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.
TSVN is not a wrapper around a command line client. It is linked against
the library and doesn't use the command line client at all.
If you like, you can try a GUI client which wraps around the command
line client (I know there is one, don't remember its name - just Google
for it). But I'm sure it won't work reliably (if you know about unicode,
languages and how to write code, you'll know why).
> 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).
RapidSVN doesn't wrap around the command line client either. It too is
linked directly to the Subversion library. Which means you'll have the
very same problems.
> 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.
You're trying to solve your problem from the wrong direction. Instead of
trying to force certain versions of SVN clients, you should instead use
the *right* clients to do the job. As mentioned before: *never, ever*
use the cygwin svn client together with any other svn client on the same
working copy. The Subversion team dropped the compatibility of working
copies between different platforms long ago because it never really
worked anyway.
TSVN usually releases a new version a few days after the official
Subversion client gets released. So you won't have compatibility
problems if you use that one. If the working copy format changes in
between versions, there's always a big note on each of the websites
(TSVN and SVN) indicating that.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Aug 3 23:35:55 2007