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

Re: Another working copy library

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2007-01-30 16:01:50 CET

On 1/30/07, Greg Stein <gstein@lyra.org> wrote:
> On 1/30/07, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 1/30/07, Greg Stein <gstein@lyra.org> wrote:
> >
> > > And FWIW, I am very, very strongly against any notion of 2.0.
> > > Personally, I see it as a failure in creativity. Shooting for 2.0 is a
> > > shortcut. It's a way to avoid the difficult problems. It is a way to
> > > shove development problems/maintenance at the bazillions of users that
> > > Subversion has today. Consider: 1.x clients and 2.0 servers are not
> > > compatible. 2.x clients and 1.x servers are not compatible.
> >
> > FWIW, there's no reason that we have to drop client/server compat for
> > 2.0. We've always said we weren't required to keep compat between
> > major versions, but we don't have to get rid of all of it. It's
> > perfectly reasonable IMO for us to decide to drop working copy and
> > binary compat while keeping network protocol compat.
> Ah. Fair enough. I guess it is conceivable to have a 2.0 that revs
> only the library APIs (e.g. removing cruft), but is otherwise
> *exactly* the same to the user.
> I still think it will freak people out, and would want to avoid 2.0 at
> all costs, but hey... you're right in that it doesn't mean incompat
> clients/servers.

I agree that having the client library API be reved (and WC incompatibility)
at the 2.0 revision would not require a network layer change. In fact,
it would be best (IMHO) if it did not.

This thread brought on a flashback to 1989-1991 for me with the talk of
"version 2.0 breaks everything" as that was the talk in the AmigaOS
development group - 1.4 was what we were building and it was going
to be compatible but 2.0 was not. We tried to explain the rules, etc.
Marketing and common sense came and changed that - 2.0 (2.0.4) was
a major change/enhancement to the OS and yet still provided a
significant change to many parts of the system. We just had lots of
compatibility shims and tricks we had to play.

Having lived through a number of system updates/replacement projects,
it would make for a much better adoption process to have the break
be in one spot only rather than drastically across the board. Other than
WC incompatibilities, everything else should be possible to have
compatibility shims to some level. (Well, if we are lucky it should be)

Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
Received on Tue Jan 30 16:02:11 2007

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