X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.5 required=5.0 tests=AWL,BAYES_00
X-Spam-Check-By:	sourceware.org
Message-ID:	<4EC53A81.3040307@bopp.net>
Date:	Thu, 17 Nov 2011 10:46:57 -0600
From:	Jeremy Bopp <jeremy AT bopp DOT net>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Rolling back to 1.6.x Subversion
References:	<D0CBCC01C005D44CB4009B8A6B532BE41F0B731B AT IAD2MBX11 DOT mex02 DOT mlsrvr DOT com> <e6d63495-2b2f-438a-8308-4bf9e61aef0d AT email DOT android DOT com> <1872837516 DOT 20111117113945 AT mtu-net DOT ru> <4EC52A2C DOT 1030905 AT bopp DOT net> <CAG_2cTkqGy7MXx2K0d78PfKG2mvDq-oy5aJcWEic1AeLwd4xWA AT mail DOT gmail DOT com>
In-Reply-To:	<CAG_2cTkqGy7MXx2K0d78PfKG2mvDq-oy5aJcWEic1AeLwd4xWA@mail.gmail.com>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 11/17/2011 10:09, Jon Clugston wrote:
> On Thu, Nov 17, 2011 at 10:37 AM, Jeremy Bopp <jeremy AT bopp DOT net> wrote:
>> I want to think that they only change the working copy format when the
>> minor version changes, but I also think that they have done that with
>> every minor version transition since at least 1.4.  I know I remember
>> seeing the client request to upgrade my working copies at least once
>> before anyway.  Whether or not that upgrade was required, I can't say.
> 
> This is all explained quite clearly in the documentation on the
> Subversion web site.  Each minor release is allowed to change the
> working copy format in a non-compatible way (the lower numbered
> clients can't safely use it).  This simplifies the development of
> Subversion but causes a (to me at least) very minor annoyance that all
> clients that will use the same working copy must be at the same minor
> release.  This, however, doesn't stop anyone else who writes
> Subversion clients from transparently supporting multiple client
> versions simultaneously (and dealing with the complexity that
> creates).

Thank you for confirming my memory regarding these format changes.
Still, while it makes sense for the project to make backward
incompatible changes at times, it still seems odd that the new clients
wouldn't support using the working copies from at least 1 minor version
back in order to ease interoperability between SVN client implementations.

I could see that the new clients wouldn't *create* older version working
copies in order to encourage adoption of the changes, but it wouldn't
seem too hard on the face of it to keep around a compatibility layer
from the last minor version in order to *use* an older working copy.
It's the maintainers' decision how they build their project, of course.
 I just find this aspect surprising.

-Jeremy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -