[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: Mon, 7 Nov 2011 08:45:11 -0800 (PST)

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

> From: Stefan Küng <tortoisesvn_at_gmail.com>
> To: dev_at_tortoisesvn.tigris.org
> Cc:
> Sent: Wednesday, November 2, 2011 2:55 PM
> Subject: Re: Feature Request: svn:externals dialog update...
>
> On 01.11.2011 23:10, BRM wrote:
>>> From: Simon Large<simon.tortoisesvn_at_gmail.com> To:
>>> dev_at_tortoisesvn.tigris.org Sent: Tuesday, November 1, 2011 5:33 PM
>>> Subject: Re: Feature Request: svn:externals dialog update...
>>>
>>> On 1 November 2011 18:22, BRM<bm_witness_at_yahoo.com>  wrote:
>>>> I just upgraded to the 1.7 series and noticed the change in the
>>>> svn:externals property dialog. Overall, I really like it.
>>>> However, I am presently in a situation where not all of the users
>>>> of my SVN repository use a version of SVN that uses the newer
>>>> svn:externals format (some are still using SVN 1.4) and I have no
>>>> way of forcing them to upgrade. The new dialog, however, puts out
>>>> the newer format when used, and comes up by default when clicking
>>>> the "Edit". So, I would like to make a simple feature
> request - a
>>>> simple boolean setting (TortoiseSVN->Settings->Advanced) that
> is
>>>> disabled by default that allows the user to determine which
>>>> dialog comes up by default when editing the svn:externals - if
>>>> set to FALSE then the new dialog is displayed (default behavior),
>>>> if set to TRUE then the Advanced (old-style) dialog is
>>>> displayed. This should only affect the default behavior of the
>>>> 'Edit' button; users should still be able to go to either
> dialog
>>>> by using the arrow to access the menu and select the dialog
>>>> (presently 'Default' and 'Advanced', though this
> should probably
>>>> be 'Default', 'Simple', and 'Advanced' with
> this change.)
>>>
>>> You do know that you can just use the advanced option anyway,
>>> don't you, both when editing and when creating new properties. Does
>>> this really need a hidden option to enforce it?
>>
>>
>> Yes, I am aware that you can use it any way; however, I would like an
>> option so that I can set it and not have to remember to use it. And
>> more importantly, I want to be able to tell my compatriots that they
>> can just set an option instead of having to remember otherwise
>> someone might accidentally set something that someone else won't be
>> able to use.
>>
>> So this is more of a setting to use as a preventative option for
>> teams that have to deal with old (series 1.4 and older) subversion
>> clients; either as a migration option or simply to keep things as
>> is.
>>
>> That said, the option could simply be to keep the format of the
>> svn:externals in the old format vs. the new format (disabling Peg
>> revisions, etc. appropriately) if it already is in the old format,
>> perhaps with a button/checkbox to re-enable it and force the update
>> of the syntax - e.g. don't change the formatting unless specifically
>> instructed to do so.  Either method would work.
>>
>>
>> While I would love to live in a world where such options are not
>> required/needed, they are nonetheless useful.
>
> I'm sorry, but the 'new' format for svn:externals isn't new
> anymore, it
> exists since svn 1.5.
> That's now two major versions behind. Only 1.4 clients or even older
> don't know this format yet. And since those ancient versions aren't even
>
> supported anymore, you just have to update those old clients of yours.
> Not just for the new format of the externals, but for security reasons:
> there are no security updates for those versions available anymore, and
> as you might have noticed, there were a few security fixes done in 1.6
> and backported to 1.5, but not 1.4.
> So I won't add an option to support insecure clients.

They're the only option for people using Ubuntu 8.04 LTS (long term service) as Ubuntu has not updated it past 1.4 series.
So there is still support there from some Linux Distros, though yes, not from SVN itself. I have already offered builds of 1.6 series, but getting adoption is a different issue that is far harder than having such a simple option in place in TSVN for compatibility reasons. I am sure I am not the only one that will be having this issue, though I will agree it will certainly be in the minority.

And I'm sure you'll still find people on the SVN list still using 1.3 and 1.4 for their servers which also won't support the "new" format. (Yes, I am aware it was introduced in 1.5 so it's not 'new' any more. However, it is NEW that TSVN is forcing the conversion of the format via this default dialog for editing svn:externals. SVN 1.5/1.6/1.7 itself is happy to continue using either format.

This also ignores that people may have other tools - scripts, etc - that may parse the format and may not have upgraded to the 'new' format as the rest of their tool set may not support it yet either. Now I am not personally in that boat  - that is just another example of why such an option is valid to have. This kind of change should be something that TSVN/SVN users consciously make, not one that is made in the background for them.

So it's not necessarily about supporting insecure clients, but it is necessarily about allowing people to consciously decide when they will make the change instead of having it forced upon them. It would be different if SVN entirely dropped support for the old format, but they haven't - they still document and comment on it in the current nightly documentation (http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html), and list good reasons to upgrade to the 'new' but do not force anyone to upgrade the format.

Ben

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

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-11-07 17:45:21 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.