Upcoming Flag Day

Ben Collins-Sussman <sussman@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