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
Received on Mon Aug 6 18:17:54 2007