public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jeremy Bopp <jeremy@bopp.net>
To: cygwin@cygwin.com
Subject: Re: Rolling back to 1.6.x Subversion
Date: Thu, 17 Nov 2011 16:47:00 -0000	[thread overview]
Message-ID: <4EC53A81.3040307@bopp.net> (raw)
In-Reply-To: <CAG_2cTkqGy7MXx2K0d78PfKG2mvDq-oy5aJcWEic1AeLwd4xWA@mail.gmail.com>

On 11/17/2011 10:09, Jon Clugston wrote:
> On Thu, Nov 17, 2011 at 10:37 AM, Jeremy Bopp <jeremy@bopp.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

  reply	other threads:[~2011-11-17 16:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 23:06 Jim Garrison
2011-11-17  0:53 ` Jeremy Bopp
2011-11-17  7:50   ` Andrey Repin
2011-11-17 15:37     ` Jeremy Bopp
2011-11-17 16:10       ` Jon Clugston
2011-11-17 16:47         ` Jeremy Bopp [this message]
2011-11-17 19:05           ` Andrey Repin
2011-11-17  9:10 ` Andy Koppe
2011-11-17 11:12   ` Csaba Raduly
2011-11-17 16:33     ` Jeremy Bopp
2011-11-17 19:05   ` Andrey Repin
  -- strict thread matches above, loose matches on Subject: below --
2011-11-15 21:47 Sean LeBlanc
2011-11-16 15:18 ` Jeremy Bopp
2011-11-16 21:16   ` David Rothenberger
2011-11-16 22:35   ` Andrey Repin
2011-11-16 23:01     ` David Rothenberger
2011-11-17 19:06     ` Warren Young
2011-11-17 22:50       ` Andrey Repin
2011-11-18  0:14         ` Warren Young
2011-11-18  9:50           ` Andrey Repin
2011-11-18 14:25           ` Csaba Raduly
2011-11-18 17:23             ` Dave Korn
2011-11-19  9:30             ` Warren Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EC53A81.3040307@bopp.net \
    --to=jeremy@bopp.net \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).