The Cygwin svn CLI client works fine, and has been totally error-free
for me. We use Cygwin because it provides a single-point of update for
a broad array of pre-packaged utilities. While Windows-native instances
exist for some of these tools, most of which are faster than the
corresponding Cygwin build, only Cygwin provides us with a single
integrated update mechanism. Only Cygwin builds from the original GNU
sources, ensuring developer builds done under Windows are compatible
with builds done on our mix of Windows and Linux production servers.
TortoiseSVN provides a rather different notion of compatibility.
The fact that TortoiseSVN does not include the matching CLI app baffles
me. It would be a trivial addition to the project. Even if the actual
CLI binary weren't included, the TortoiseSVN installer could simply
offer to TRY to get and install the corresponding CLI as part of the
installation/upgrade process. At the very least, the installer should
attempt to run the local CLI svn instance and try to detect the
incompatibility before a user crashes into the problem.
With Cygwin in my path, "svn --version --quiet" writes the string
"1.4.3" to stdout. Why can't TortoiseSVN do likewise (so Ant and Make
can do the check)? Why can't the TortoiseSVN installer try to run "svn
--version --quiet" and check the result (and hopefully issue a warning)
prior to doing an upgrade?
What possible reason can there be to assume the default TortoiseSNV user
would WANT their local CLI client to become outdated just because
TortoiseSVN was upgraded? Yet, for no stated logical reason, that's
what TortoiseSVN presently does: A TortoiseSVN upgrade can needlessly
break your build system.
I view SVN as an important part of my development infrastructure, much
like my compiler.
What if a vendor made a compiler designed to work ONLY through an IDE,
making it totally incompatible with tools like Make and Ant. Would you
use such a compiler to create TortoiseSVN itself? I suspect not. What
if this compiler vendor said, "We're 100% GCC compatible!", but did
nothing to ensure that the compatibility actually existed on the client
installation.
Now, let's make it worse: Your GUI-only compiler provides no means to
validate itself against the CLI compiler, nor does it permit CLI tools
to easily check its language compatibility. All you get is an
unsubstantiated claim of compatibility that has no way to prove itself.
The GUI compiler provides no text output to stdout, making it very
difficult for a build script to ensure that the CLI tool can generate
what the GUI user expects.
That's the description of a toy, not a tool. Would you install such a
GUI-only compiler on your system?
Yet some people appear to believe that such a model IS the right way to
do things, to PREVENT automatic integration between a GUI app and its
CLI equivalent. They offer no logic whatsoever why this approach is
best: It seems to be a purely religious issue, having no apparent link
with logic and reason.
Me, I'm just looking for tools that try real hard to play nice together.
To improve build quality, rather than degrade it. To simplify systems
administration, rather than complicate it. To assist end-users, rather
than confuse them.
-BobC
-----Original Message-----
From: Simon Large [mailto:simon.tortoisesvn@googlemail.com]
Sent: Friday, August 03, 2007 2:15 PM
To: users@tortoisesvn.tigris.org
Subject: Re: Determining TrotoiseSVN version from a script.
On 03/08/2007, Bob Cunningham <bcunningham@sandel.com> 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 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.
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 not
guaranteed.
> 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 related.
> 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.
Simon
--
___
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Mon Aug 6 17:49:30 2007