I couldn't resist rebutting the quoted reply point-by-point, but you may prefer to bypass those comments and jump to the end.
-BobC
Stefan Küng wrote:
> Bob Cunningham wrote:
>> 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).
>
> And I thought that both claim to be image editors. Sorry I assumed
> that they both are implementations of an 'image editor', which is
> obviously not the same thing...
That would be like comparing a git client to TortoiseSVN. They are both doing "version control", but are totally different tools.
Stop mixing apples and cantaloupes.
>> 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!
>
> So what you're saying here is that we only have to check for the CLI
> version because that's what you're using.
No, just assume that any self-respecting svn CLI client will report version information just like the mainline SVN CLI client. If it doesn't, then assume it is not compatible. Just let us know why the test failed:
1. No local svn CLI, so no failure possible.
2. Local svn CLI found, but output version string looks odd: "Error: Local SVN CLI client version not recognizable."
3. Local svn CLI found, output version string is in the right format, but it is the wrong version: "Error: Local SVN CLI client not compatible with this version of TortoiseSVN" (If it's in the installer, add the option to cancel the installation.)
4. Local svn CLI found, output version string is GOOD: No message needed
>> 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."
>
> TSVN. is. not. a. command. line. client.
> TSVN. is. not. a. command. line. client.
> TSVN. is. not. a. command. line. client.
Pardon me, my bad: I meant the "T" to mean "Tigris". My goof! Let me rephrase: Have you found any binary svn CLI client for Windows that is not compatible with the svn CLI Windows client available at subversion.tigris.org?
>> Every Windows GUI app can have easy access to stdin/stdout/stderr.
>> Shall I point you to the relevant APIs in MSDN?
>
> Yes please do! But to those which work on Win2k too. And of course to
> those which not just create a new stdout but attach themselves to the
> existing stdout, because that's what you would need to catch the
> output from your script.
>
> If you have something that really works, you should write an article
> about that: a lot of people would love to know how that's done.
Arrgh. I'm not A Windows Programmer: I just whack at the stuff until it works. Years ago I wrote a really simple Windows GUI app to wrap one of our legacy DOS CLI tools (that still works, so why fix it). Here's what I used for that app: http://support.microsoft.com/kb/q190351/
Though I don't know for sure, I believe it should work for NT4/W3k/XP/Vista.
>> 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.
>
> Every IDE out there calls the compiler, which is kept as a separate
> exe file and implemented as a console application.
> TortoiseSVN does not use the svn.exe but links to the library (as I
> now mentioned three times already).
Yes, that's OBVIOUS. And that's the PROBLEM: This wouldn't be an issue if the CLI were being wrapped! Then, the CLI would be there, and it would be the only SVN code being used by ALL users, including wrappers.
But TSVN provides its own implementation, one that can easily conflict with a CLI that was there prior to TSVN, or may be added after TSVN. Reconciling those instances, and preventing/detecting mismatches, is the issue we've been discussing.
>> 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.
>
> You haven't been on this list for long enough to make such an
> assumption. If you had, you would know that most people *don't* have
> the CLI installed and don't need it.
> You can't just assume that most people work as you do (and honestly:
> I hope they don't).
TSVN in the ONLY tool we use that has redundant and potentially conflicting implementations on a single platform. All of our other GUI tools that have CLIs are just wrappers for the CLI, and so can't possibly introduce client-side conflicts.
>> 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.
>
> What does that have to do with TSVN not shipping the CLI or your
> incompatibility problems?
It was just an example of a project that chose NOT to replace CLI apps with native implementations within their GUI.
>> 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.
>
> "For every problem there is a solution which is simple, clean and
> wrong."
>
> Let's assume just for a second that TSVN would do what you ask:
>
> shipping the SVN CLI with TSVN:
> * where should it get installed?
> - default location: we would possibly overwrite an existing
> installation, which could be in use by e.g. Apache. Which
> means we would break that!
> - in the TSVN subfolder: then a user could have two instances
> of the CLI installed. Which means even more incompatibility
> problems.
Come on! Are you really this uninformed? Do I need to use simple words? OK, here goes, the secrets of the universe revealed just for you: You install the CLI with TSVN, and place the bin directory in the path (that's %PATH% for you Windows/DOS folks).
If you prompt for the install to be "Available for all users", you put it in the System PATH variable. Otherwise, you put it in the User PATH variable.
> * how to deal with upgrades?
> - not installing at all if an older version exists: No upgrade
> possible, because an earlier version of TSVN could be the
> reason for the older CLI version. Users would have to manually
> uninstall TSVN first, then install the new version.
> - let the user choose what to do: the average user won't know
> what to do, and either freak out or just hit ESC in that dialog.
A simple warning will do.
TSVN is currently silent on the entire issue. ANYTHING would be a vast improvement. Make it nag like the update reminder dialog.
> Checking for older versions of the CLI first:
> * if the CLI is used for the server part and not for the client part,
> then an upgrade of TSVN would never be possible. Many people don't
> upgrade the server with every new version that gets released.
We've been talking only about the client here. Which is all TSVN presently deals with.
If you want TSVN to check server compatibility, then TSVN should do that no matter if a CLI client exists or not! (Actually, I don't know if you do or don't do such a check. But it would be nice if you did.)
>> 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.
>
> Tell that the Cygwin guys. Cygwin tries to play nice with Linux apps,
> not Windows apps. That's where your problems come from.
You are wrong: I have never said there is a conflict between Cygwin and TSVN.
The conflict is between TSVN and ***ANY*** incompatible svn client, no matter if it is from Tigris or Cygwin.
I know for a fact that the Tigris svn CLI and the Cygwin svn CLI play nice together. The server doesn't care which one it talks to, and our apps don't care which one is used. We picked Cygwin only because it was easier to update.
> But if you would have read our answers (*really* read them), you
> would have discovered long ago that your problems don't come from the
> fact that there are different versions of SVN clients on your system
> but from the fact that the Cygwin SVN client is not compatible with
> native SVN clients. Nothing will ever change that.
WRONG! Please read closer. Or, better yet, go get an old TSVN and a matching svn CLI. Now, wait for TSVN to nag you about the update for 1.4.4. Do the upgrade. See what happens. No surprises there, right? It has nothing to do with Cygwin, right?
Now, let's go back to the original topic: TSVN could be made to do a simple CLI check at install time, and it could also do one (if desired) at run time. Presently, it does nothing.
> If however you want to make sure that all SVN clients have the same
> version, then use the GetVers.exe tool.
>
> Stefan
For now, that's all we have. However, it is certainly more than I had when I started this thread!
Thanks, Stephan, for pointing me to GetVers.exe.
Still, for the umptyleventh time, let me repeat (FOR THE LAST TIME, I promise) that I believe it would be truly useful if the TSVN installer would *try* to detect an incompatible CLI as part of the install process. The same code may be useful for the Upgrade nag box too, to remind the user that their CLI may need to be update along with TSVN.
Better yet would be for the TSVN installer to include its own CLI instance, and kill the entire issue (including any possible Cygwin issues too!). No need for a version compatibility check, in that case.
From my perspective, it's really about being a "one stop, full service, Windows SVN client shop". TSVN is the best svn GUI I've seen. No, it's more than that: It's the best GUI I've seen for ANY revision control product. TSVN is also the best Windows Explorer extension I've ever seen (QTTabBar being a distant second).
If you didn't have such a great product, I wouldn't have nagged so hard. TSVN really is that great, verging on "Almost Perfect".
-BobC
PS: Outlook-QuoteFix rocks! Thanks, Andy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Mon Aug 6 20:56:08 2007