On 03/08/2007, Bob Cunningham <firstname.lastname@example.org> 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).
There's your first problem. You should never use the Cygwin client on
the same working copy as a Windows client. There is absolutely no
guarantee of WC compatibility between (effectively) different OSs.
Maybe it will work, maybe it won't.
> 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.)
If you were using TSVN and a true Windows client you would not get
corrupted WCs. You might get *upgraded* WCs which no longer work with
the older client, so then you have to upgrade the other client too.
> 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
> Something like a "/version" switch for TortoiseProc would do nicely, but
> only if it outputs text to stdout instead of invoking the About box.
Not available currently. What you need in any case is not the
TortoiseSVN version but the subversion library version that it is
linked to. In general the version numbers track roughly, but that is
> Alternatively, it would be great if TortoiseSVN simply included a compatible
> command-line client (both get updated together).
Get the command line client directly from subversion.tigris.org, but
they will not be updated together because they are not directly
> Better yet (from an automation perspective) would be a mode where
> TortoiseSVN would output text for the equivalent svn command line.
If you need that information you can get it from the help file.
> 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.
It is *a* reason, but IMHO a very weak reason. Your the first person I
have ever come across with this particular 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).
Of course. You must use the tools which suit your particular needs
best. For automation, TSVN is definitely not the tool of choice.
> 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.
If you want a scriptable client, use the command line client, not TSVN.
> 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.
The Windows CLI is 100% compatible.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Aug 3 23:13:10 2007