From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18004 invoked by alias); 17 Nov 2011 16:47:16 -0000 Received: (qmail 17992 invoked by uid 22791); 17 Nov 2011 16:47:12 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail31.mailforbusiness.com (HELO mail31.mailforbusiness.com) (64.106.208.204) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Nov 2011 16:46:59 +0000 Received: from mail31.mailforbusiness.com (localhost.simplicato.com [127.0.0.1]) by mail31.mailforbusiness.com (Postfix) with ESMTP id 2D66372BEB5 for ; Thu, 17 Nov 2011 11:46:58 -0500 (EST) Received: from [10.10.50.65] (67-198-47-100.static.grandenetworks.net [67.198.47.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeremy@bopp.net) by mail31.mailforbusiness.com (Postfix) with ESMTPSA id 031C372BEB1 for ; Thu, 17 Nov 2011 11:46:57 -0500 (EST) Message-ID: <4EC53A81.3040307@bopp.net> Date: Thu, 17 Nov 2011 16:47:00 -0000 From: Jeremy Bopp User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Rolling back to 1.6.x Subversion References: <1872837516.20111117113945@mtu-net.ru> <4EC52A2C.1030905@bopp.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-11/txt/msg00308.txt.bz2 On 11/17/2011 10:09, Jon Clugston wrote: > On Thu, Nov 17, 2011 at 10:37 AM, Jeremy Bopp 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