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

Re: Compatibility, and Frustration.

From: <cmpilato_at_collab.net>
Date: 2003-03-21 16:03:37 CET

Ask Bjoern Hansen <ask@develooper.com> writes:

> On Wed, 12 Mar 2003, Karl Fogel wrote:
>
> A question and a few suggestions:
>
> How does this relate to the repository? Can I expect the server not
> to croak on the repository after an upgrade?

You can expect the server not to croak on a upgrade that is done by
the recommended upgrade procedure for that new release, which might be
the implied trivial procedure (build, install), or might specify that
a repository dump/load have to be done, or that you need to frob the
guzzlebucket bit on the humperdinker.

> How about maintaining an "UPDATING" file like the FreeBSD project
> does. It's a bit like the CHANGES file, except it only has notes
> about compatibility related changes and it's updated continuously.
> After updating your source tree and before compiling and installing
> you'll do a quick check of the UPDATING file.

An interesting idea, but I think the CHANGES file is sufficient.

> Maybe it would be useful to have the client print a warning when
> it's accessing a server that's too new or too old? Maybe using
> something like the Apache httpd flag used for binary modules (I
> momentarily forgot the name). When an incompatible change is
> introduced the version/flag is bumped and the client will be able to
> tell.

We try to do this as much as possible. For example, we have 'format'
files in the working copy and repository that indicate what version of
the each of those things is present. This allows codepaths to
compensate for various scenarios, or to gracefully fail. But we have
yet to put version numbers on the client/server protocols.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 21 16:06:20 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.