Bob Cunningham wrote:
> 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.
You're comparing a console application with a GUI application. IMHO
those are further apart than two image editors.
>>> 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
TSVN does that too. In the about dialog.
You want something that doesn't work for a GUI client, and you simply
refuse to use a tool I recommended which would solve all your problems.
Use the tool to extract the version info in your script and you have
what you need.
>>> 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
TSVN = TortoiseSVN.
and tigris.org is not a company. It's something like sourceforge: it
hosts independent open source projects.
> 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?
Yes. As all release notes of any svn client (there only is *one* SVN
CLI) clearly state that the working copy format changed between 1.3.x
and 1.4.x. So any svn client is incompatible with any other if they're
from those different major versions.
>>> 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/
You were talking about TSVN *writing* something to stdout.
Reading from stdout is easy.
> 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.
I hope this is meant as a joke. You can't be *seriously* thinking that
wrapping around a command line tool is better than using an API.
> 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.
Imagine what would happen if all SVN clients would wrap around the CLI.
(I'm waiting....)
Found the problem? No?
A little hint: the same problems arise from apps using the same shared
dll (share object *.so on Linux). It's sometimes referred to as "dll hell".
> 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.
So you use a lot of tools which wrap around the CLI. That means you have
never used your scripts and tools on a non-english OS. Because you would
know right away that wrappers are bad.
> 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).
I'm more informed than you. It's pretty obvious that you have never
written a (working) program on Windows.
> 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.
Sure, and then you wait for angry users asking for your address on the
mailing list because they all want to pay you a visit and beat you up.
I know how to install a console app. But you simply refuse to read my
arguments above. Otherwise you would know that it's not that simple and
your simplest approach would just break many, many installations. Sure,
TSVN and the CLI would work, but you would break other apps.
>> 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.
I give up. Seriously. I can't do more than explain, and you obviously
don't *want* to understand.
> The conflict is between TSVN and ***ANY*** incompatible svn client,
> no matter if it is from Tigris or Cygwin.
Ok. The only incompatibility between native SVN clients is between
versions 1.3.x and 1.4.x.
And you can talk to your people and explain to them that they have to
update their clients accordingly. You know which clients they use (and
which your script needs). Write a document where you list the compatible
clients, for example:
SVN CLI: 1.3.0, 1.3.1, 1.3.2, ...
TSVN: 1.3.0, 1.3.1, 1.3.2, ...
or
SVN CLI: 1.4.0, 1.4.1, 1.4.2, ...
TSVN: 1.4.0, 1.4.1, 1.4.2, ...
> 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.
Your choice. If you know "for a fact" that they are completely
compatible then go on. There's no need for you to believe a SVN client
developer or other experienced users who tell you otherwise.
Just do me a favor: if your whole working copy or build script fails
completely one day, don't come complaining to us.
> 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.
No, as I mentioned four times already: we won't do such a check. Because
it's useless, dangerous and won't work reliably.
And you can do that check yourself. I've mentioned the tool you can use
several times now.
> 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.
If you would really read and try to understand my arguments in the last
mail, you would know that this is not something that we even *should*
consider doing.
> 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.
And I've told you more than once that we won't do that for several
reasons (I won't list all the reasons again, read my mails from before).
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
Received on Mon Aug 6 22:35:36 2007