On 8/3/07, Bob Cunningham <bcunningham@sandel.com> wrote:
>
>
> 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?
>
> 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.
>
There are many tools for windows to audit installed programs. You
might be better served using them conduct audits of installed programs
(and their versions).
There are probably even some programs around that can grab the version
details from an EXE file (I believe it's a fairly standard MS format).
You could use such a program (or write one) to get the TSVN proc exe
version information.
I understand the problem of TSVN and svn getting out of sync ---
either can silently upgrade working copies that will then no longer
work with the other client.
However, your case seems to be an issue of wanting to use a program to
fix problems of people not following procedures. If you tell your
people to NOT install new versions, and they do, yell at them. If
they keep doing it, fire them.
Alternatively, lock down the computers so that users can not do those
things. NOTE: even if you lock down the computer, a user could still
unpack an svn-win32*.zip distribution into his path.
Locking down the computers rarely solves as many problems as it creates.
Threating to not use TSVN if the problems aren't fixed to your
satisfaction, is probably not very helpful.
That said, some of the items you mentioned (having the /version
qualifier) could provide some benefits (e.g. sanity checking in
scripts) and not interfere with other TSVN functions.
Another possibility for the TSVN team: since it is so common to want
both TSVN and the SVN command line clients, perhaps TSVN could, as an
option, be bundled with the svn command line clients (and SVN Book)
and thus share all the libraries, config files, etc... from one
install? I'm not sure how much work that would be to add, but it has
the potential of preempting many of these problems. It may just be
more of a headache than anything else. The only real difficulty I've
seen in keeping TSVN and SVN in sync is that TSVN releases new builds
faster than the SVN group get their Windows install files up. You can
still use the zip files though.
- Kevin
---------------------------------------------------------------------
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:29:32 2007