You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2002/08/06 21:29:32 UTC
Upcoming Flag Day
Ben Collins-Sussman <su...@collab.net> writes:
> sussman@tigris.org writes:
>
> > Summarize commit logs since Alpha, in preparation for an "Alpha
> > Interim 1" release.
> >
> > + * started fs branch work on #842 (copyID inheritance), #830 (copies of
> > + copies), #790 (copy table uses txnID), #815 (custom sorting)
>
> Wow, lots of CHANGES in the last two weeks since alpha!
>
> I think that once cmpilato has merged his latest branch back into
> /trunk, that could be our signal for a 0.14.1 interim release. It
> will require another repository dump/load.
>
> (Also, we might want to get the '.prop-base' suffix patch into
> libsvn_wc as well, assuming it has some backward-compatibility code in
> it.)
...and then Ben and Karl and Mike talk about it, and poo-poo all over
that mess.
--
Subversion is about to suffer several changes that will cause
incompatibility between clients and servers, servers and filesystems,
clients and working copies, Hatfields and McCoys, etc.
- KBP's ".svn-base" property file suffix patch (Issue #618).
- DAV namespace property reorganization (Issue #840).
- Subversion error space reorganization (Issue #702).
- Repository dump/load (Issues #842, #830, #790, #815 ... dang!).
- Others? (please let us know now!)
With so many things changing, we can at least amortize the pain of a
flag day by getting the most benefit out of it. :-) Furthermore, this
time we will introduce version numbers for each of the things that is
changing incompatibly, so that future incompatible changes can be
easily detected. Specifically:
- Kevin, can you please add code to your patch to read the
.svn/format file, and do the right thing. See how init_adm() is
hard-coded to write out a version number of '1' to the "format"
file? That's naughty. We should have a #define for our current
working version number (and as of your patch's addition, that
number should be bumped to '2'). svn_wc_check_wc() should error
out if it is reading the wrong format.
- Me, could you please add a version number for the repository?
Sure, I will. Oh, and could old repos's be assumed to be version
0? I don't see why not. Coolio, Daddio.
- Ooooooooh Greeeeeeeeeg (Stein): How can we define a protocol
version for our DAVish communications? Not so much our use of DAV
itself, but all those custom reports and responses and such? We
just need to detect incompatibility, not correct for it at
runtime, wethinks. Interestingly enough, this particular instance
of a version number isn't so important for *this* flag day, since
nobody's servers *or* clients are going to work until fully
upgraded. :-)
The result of all this is that if people need to upgrade either their
server or their client, they will be clearly informed of this via
friendly Subversion error messages (as opposed to "BerkeleyDB error:
what the hell?!").
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upcoming Flag Day
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > just need to detect incompatibility, not correct for it at
> > runtime, wethinks. Interestingly enough, this particular instance
> > of a version number isn't so important for *this* flag day, since
> > nobody's servers *or* clients are going to work until fully
> > upgraded. :-)
>
> Huh? That should never happen. We should *never* change the client or server
> so radically that people are forced to upgrade. We want to "accepth both"
> for a period of time, *then* remove the old.
This isn't quite what is happening, on the server side. The change
there is just this: if you *do* upgrade your server, it will tell you
you must also dump/load your repository, and it won't work until you
do, that's all.
For the client, it would be great if Kevin can make the code be
both-ways compatible for a while, and then we'll phase out the old
code. And if we do the same thing for the DAV namespaces, then
there's no need for a flag day.
> What changes are you thinking of? Have we done this lately? Or planning to
> at any point?
The ones Mike listed (he gave the issues, I don't remember them).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upcoming Flag Day
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 06, 2002 at 04:29:32PM -0500, cmpilato@collab.net wrote:
>...
> Subversion is about to suffer several changes that will cause
> incompatibility between clients and servers, servers and filesystems,
> clients and working copies, Hatfields and McCoys, etc.
>
> - KBP's ".svn-base" property file suffix patch (Issue #618).
> - DAV namespace property reorganization (Issue #840).
The client should recognize both, and the server should continue to use the
old namespaces for a while. At some future point, the server will begin to
use the new namespaces. "Really old" clients will need to be upgraded.
>...
> - Ooooooooh Greeeeeeeeeg (Stein): How can we define a protocol
> version for our DAVish communications? Not so much our use of DAV
> itself, but all those custom reports and responses and such? We
The names and namespaces and things give us plenty of "versioning"
capability, along with negotiation and whatnot.
> just need to detect incompatibility, not correct for it at
> runtime, wethinks. Interestingly enough, this particular instance
> of a version number isn't so important for *this* flag day, since
> nobody's servers *or* clients are going to work until fully
> upgraded. :-)
Huh? That should never happen. We should *never* change the client or server
so radically that people are forced to upgrade. We want to "accepth both"
for a period of time, *then* remove the old.
What changes are you thinking of? Have we done this lately? Or planning to
at any point?
Cheers,
-g
p.s. note that we *could* code the client to understand the old namespaces
and issue a warning "your server needs to be upgraded"
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org