X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,TW_SV X-Spam-Check-By: sourceware.org Message-ID: <4EC52A2C.1030905@bopp.net> Date: Thu, 17 Nov 2011 09:37:16 -0600 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: Andrey Repin Subject: Re: Rolling back to 1.6.x Subversion References:

<1872837516 DOT 20111117113945 AT mtu-net DOT ru> In-Reply-To: <1872837516.20111117113945@mtu-net.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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 01:39, Andrey Repin wrote: > Greetings, Jeremy Bopp! > >> All I really wanted to know was why it was important to hang back from the >> latest available version when getting the older one was less than trivial. >> Not using anything more than the command line for svn (infrequently at that) >> made me forget how often that project changes formats in the working copies >> and the ramifications of that behavior. > > On my memory, it wasn't changed even once in four years. Or all changes were > transparent. > The main problem with 1.7 I see myself, I described earlier: No way to tell at > a glance, if the directory you're working with is versioned or not. 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. Regardless of the time period between minor version bumps, that rate of change in working copies seems excessive to me given the relative stability of other SCM tools, but that's just my likely ignorant opinion. ;-) Maybe like you say, the other transitions allowed for some backward compatible support. It's odd then that they wouldn't allow for that in the 1.7 client. I would expect the 1.7 client to at least support *using* existing version 1.6 working copies in order to avoid exactly this sort of interoperability issue, but it sounds like it does not. That's very unfortunate if true. If true, maybe it would make sense to allow for parallel installation of svn versions that differ by minor number and use the alternatives system to allow the user to select a particular one if they decided to install both. In other words, it would be handy to offer something like subversion16 and subversion17 packages as well as an alias package named just subversion that would pull in the latest version. That's probably more work than it's worth though given the number of sub-packages also offered with subversion. -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