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

Re: Extend E155021 message to include supported format version

From: Andy Levy <andy.levy_at_gmail.com>
Date: Mon, 7 Jul 2014 09:45:26 -0400

On Mon, Jul 7, 2014 at 9:40 AM, Notes Jonny <jongmob_at_gmail.com> wrote:
> On Fri, Jul 4, 2014 at 4:51 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
>> On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny <jongmob_at_gmail.com> wrote:
>>> Hi Mark
>>>
>>> You are right that I did have 1.8.x installed. Which I downgraded to
>>> this version:
>>>
>>> TortoiseSVN 1.7.7, Build 22907 - 32 Bit , 2012/05/15 12:16:05
>>> Subversion 1.7.5,
>>> apr 1.4.6
>>> apr-utils 1.3.12
>>> neon 0.29.6
>>> OpenSSL 1.0.1c 10 May 2012
>>> zlib 1.2.7
>>>
>>> NB. I don't know why tortoise is called 1.7.7 and subversion uses
>>> 1.7.5 - would be simpler if they matched.
>>
>> TortoiseSVN release 1.7.7 is built on Subversion version 1.7.5.
>> Because there may be bugs in TSVN that aren't present in the
>> Subversion libraries, there may be multiple TSVN releases for a given
>> version of the Subversion libraries.
>>
>> For example, TSVN 1.7.2, 1.7.3 & 1.7.4 were all built on Subversion
>> 1.7.2; TSVN 1.7.2 had some nasty bugs that needed to be resolved
>> quickly (and 1.7.3 had one more). From the release announcement for
>> 1.7.3[1]:
>>
>> Due to some nasty bugs in TortoiseSVN 1.7.2 which in some specific
>> situations could make it crash, we're releasing this version out of sync
>> with SVN releases.
>>
>> 1.7.4 had another bug that needed quick resolution[2].
>>
>> The alternatives I can think of offhand are:
>>
>> 1) Only release TSVN in lock-step with Subversion releases, leaving
>> TSVN bugs hanging in the wild unnecessarily long
>> 2) Don't publish the library versions used in TSVN. This makes
>> debugging & error reporting tougher
>> 3) Don't bump the TSVN version number. This makes support tougher -
>> are we using the first release of 1.7.5 or the second one?
>> 4) Add yet another level to the version number scheme? 1.7.5.0, 1.7.5.1, etc.?
>>
>> The current scheme is fine IMHO.
>>
>> [1]: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2894038
>> [2]: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2908607
>
> Hello
>
> Many thanks for the replies.
>
> It sounds like the TortoseSVN team want to keep things roughly "lock
> step", I think better to be "completely lock step".
>
> I would go with: TortoiseSVN_1.7.5_Build001
>
> Just increment the Build number when they make an updated delivery of
> TortiseSVN that uses svn1.7.5
>
> Its more confusing to use a similar but different numbering scheme
> (1.7.7 and 1.7.5) in my view.

I personally see nothing wrong or confusing about the system the TSVN
folks have settled on. If anything, I think your suggestion would lead
to more confusion, having to ask people *which* 1.7.5 they're using.
What do you mean, 1.7.5 doesn't always mean the same thing?

If you'd like to lobby for a change, you'll need to take it to the
TSVN mailing list; how TortoiseSVN is managed seems to be quite
off-topic on the SVN Users mailing list.
Received on 2014-07-07 15:46:36 CEST

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

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