RE: Re: Determining TrotoiseSVN version from a script.

Comparing GIMP and Paint.Net is totally specious: They do not claim to be different implementations of the same thing. The only thing they share is file-format compatibility, something that works flawlessly (for the image formats they do share).

--
No, you don't need to do anything for "all the other svn clients out there".  Just the one that's installed and in the user's path.  If the TortoiseSVN installer were to provide that CLI instance, then the issue would be completely under your control.  If not, just run "svn" and see what you get!
Have you found **any** svn CLI instance that doesn't support "svn --version --quiet"?  I suspect none exist.  And if one did exist, all you need to do open a popup that says: "Compatibility with the installed svn CLI client could not be verified."
Even a failed compatibility check would yield useful information.  It would be far better than the present situation of doing no test at all.
--
Every Windows GUI app can have easy access to stdin/stdout/stderr.  Shall I point you to the relevant APIs in MSDN?
--
BTW, I was using the "claim" of being 100% GCC compatible as a JOKE to show how difficult it is to understand the TortoiseSVN position.  Nobody makes a GUI-only compiler, and I see no reason anybody ever would.  Which is my point:  If you are going to make a GUI-only version of an app that is first and foremost a CLI app, then you should play nice with the CLI app, whenever one is found in the user's path.
It is a simple fact that any realistically complex development project that uses TortoiseSVN will also be using a CLI svn.  This should be expected, and should be supported by TortoiseSVN, especially in code shops.  TortoiseSVN already has a GUI to use to inform the user.  TortoiseSVN already has a graphical installer.  What CLI SVN clients can boast of having this level of user interaction?  It would be a shame not to use it to try to at least minimally protect the svn CLI instance installed on the system.
For a more specific example, look at the Eclipse project discussions from a few years ago, about having a real-time compiler integrated with the editor, so syntax errors would be highlighted on the fly, just like the spell checker does in MS Word.  The fact that Eclipse supports a multitude of different compilers made the entire issue one of overwhelming complexity:  They decided to just run the selected compiler, do only basic parsing of the errors, and then simply update the Editor window with a little icon next to each line that caused a compile error.
That, it turns out, was all the user really needed.  More context-sensitive highlighting would have been nice, but not really all that useful.
Eclipse also captures the compiler output and displays it in a window.  If this can be done by a Java GUI program, it should be far easier to do it in a native Windows GUI application.  Microsoft does it with every IDE they build, including those based on .Net.
All TortoiseSVN (or the installer) would need to do is run the local "svn" CLI instance and see if the version ID is recognizable.  If is, then check to see if it compatible with the instance of TortoiseSVN.
It's not rocket-science code.  Really.
--
Finally, it is clear people don't use TortoiseSVN for its speed either:  It is obvious that speed isn't the only thing that matters.  Ease of use matters.  Manageability matters.  Standardization matters.  Compatibility matters (especially cross-platform, when needed).  Simplicity matters.  Playing nice with other tools matters.
Cygwin provides tons of great things, the only general cost being a SLIGHT slow-down (3%-10%).  It also keeps our Linux users from freaking out whenever they have to use a Windows box.  That REALLY matters!
-BobC
 
-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn@gmail.com] 
Sent: Monday, August 06, 2007 9:20 AM
To: users@tortoisesvn.tigris.org
Subject: Re: Determining TrotoiseSVN version from a script.
Bob Cunningham wrote:
> 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.
I can understand why you're using cygwin. But you're substituting easy updates with a disaster waiting to happen.
> 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.
Why should TSVN include the matching CLI? It doesn't need it! TSVN is a standalone application. The CLI is a different application. You don't see e.g. Gimp including Paint.NET, do you?
(in case you don't get my point: Gimp and Paint.NET are both image editors, while the SVN CLI and TSVN are both Subversion clients).
And why should we check for a compatible CLI installation? If we do that, then we'd have to do the same for *all* other SVN clients out there too.
You are blaming us here for your problems, even though you should know better.
> 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?
TSVN is a GUI app and doesn't have an stdout at all. Check the MSDN docs for details about that.
> 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.
What possible reason can there be to assume that a user has other SVN clients installed beside TSVN?
BTW: if you upgrade your CLI and not TSVN, the CLI will do the same. 
Have you asked on the Subversion, AnkhSVN, RapidSVN, Subclipse, ... 
mailing lists for this feature?
> I view SVN as an important part of my development infrastructure, much 
> like my compiler.
That means if you treat your compiler the same as TSVN? Ok then, that means you don't update your compiler at all before you've tested the new version on a separate system to make absolutely sure that it won't break your code or something changed which makes your project not compile anymore.
But you don't check the compatibility of TSVN with other clients. So I guess you just upgrade your compiler and pray...
> 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.
"100% GCC compatible" is bogus. You need a specific version of GCC - even GCC is not compatible to itself when the major version changes.
There are always reasons why a new version is not fully compatible with an earlier release. Subversion does the upgrade of the working copies for you so you don't even see the change.
And besides: the release notes of every SVN client I know clearly state that the working copy format has changed between 1.3.x and 1.4.x.
As my boss always says: people who can read have a clear advantage.
> 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.
I already explained (above and in my last mail) that GUI clients don't have an stdout.
> That's the description of a toy, not a tool.  Would you install such a 
> GUI-only compiler on your system?
Thanks for the insult.
I'm considering selling TSVN on Toys'R'Us.
> 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.
Once again:
TortoiseSVN: Subversion GUI client.
Subversion CLI: Official Subversion command line client.
Cygwin SVN: unsupported Subversion client. Doesn't work together with other native SVN clients.
Can you see the problem here?
Maybe I'm too optimistic...
> 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.
No, you're definitely not trying 'real hard'. As you mentioned yourself above, you're using Cygwin because it's easy to update. You use it even though you said yourself that the Cygwin tools are usually slower than their native equivalents.
So no, you're not trying hard, you're trying to blame others instead for your problems which arise from 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org