[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Determining TrotoiseSVN version from a script.

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-08-06 19:55:45 CEST

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...

> 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.

>
> 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.

> 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.

> 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).

> 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).

> 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?

> 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.
* 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.

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.

> 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.

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.

If however you want to make sure that all SVN clients have the same
version, then use the GetVers.exe tool.

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 19:53:59 2007

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.