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

Re: Feature Request: svn:externals dialog update...

From: BRM <bm_witness_at_yahoo.com>
Date: Tue, 8 Nov 2011 09:05:50 -0800 (PST)

----- Original Message -----

> From: Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se>
>> In this case, I have to advise that people either use
>> the advanced dialog (with TSVN 1.7 - which they are
>> likely to forget) or continue using the older TSVN 1.6
>> which you no longer support either. I'd much rather
>> allow them to upgrade to TSVN 1.7 and have an option
>> to set to maintain the usage we want until we are
>> ready to make the change ourselves.
>
> I don't really get it. You are happily using an old unsupported server with
> known security issues, but you absolutely want to use the latest and greatest
> client and expect it to work seamlessly.
>
> If you really want to keep 100% consistency between the server capabilities and
> the client user interface, the simplest solution is to use clients and servers
> from the same generation...

SVN itself supports interactions with multiple combinations of clients and servers. TSVN should not break that capability.

So, the SVN guys basically say "well, you want to use this functionality than you need at least server version X and client version X, but if you don't care, then you can use server version A and client version B".
See http://subversion.apache.org/docs/release-notes/1.7.html#new-feature-compatibility-table and notice the listing of "any" in that table - e.g. you can use version 1.0 or 1.7 with that server or client.

So the guys producing the SVN library that TSVN uses are saying they are compatible and valid. Yes, they're not adding security fixes, but distributions are. Even still, they are continuing support and ensuring that changes in newer versions don't break compatibility with older versions as they recognize that people upgrade the clients and servers differently, at different rates, and that sometimes people don't change them until they absolutely have to.

Now in this case, I have a _support_ 1.6 server (Debian/Ubuntu) and a _supported_ 1.7 TSVN client (on Windows), and a _supported_ 1.4 client (on Kubuntu 8.04 TLS); yet TSVN is by default forcibly upgrading repository information such that it breaks the support, while other SVN clients are not. So yes, while I have generally been very happy with TSVN for years (since 2004), this is really the first case where something TSVN is doing is completely unacceptable. And as I noted earlier, it would be different if the SVN guys were doing the same thing by dropping the older svn:externals format - but they are not - they are still maintaining support for the older svn:externals format. TSVN should do the same without forcing people to have to remember how to do it all the time as it only takes one slip-up to break the system in that case.

Remember, this is about something that SVN supports even in the latest versions. So even if we were using SVN clients and servers in all locations that were the latest 1.7 releases, it is still something that should be done by choice as there might be other tools (bash scripts, custom build tools, third party tools, etc) that may not understand the new format yet. I only have one use case, but there are many others that require the same kind of support.

> PS. Of course, another way would be to modify TSVN yourself to do seamless
> fallback for your use case; use that version yourself and offer the patch to the
> list. DS.

Well, from what I understand TSVN has a specialized environment which I don't have the capabilities to build on Windows; nor do I have the time to setup at the moment. I have considered it.

Ben

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2876324

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-11-08 18:05:57 CET

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

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