Some users and developers have expressed concerns about ra_svn
compatibility, partly because of the way we've broken compatibility in
that ra mechanism in every release since 0.20 or so. I'd like to
clarify the situation.
The ra_svn protocol has several flexible allowances for backward
compatibility, in decreasing order of desirability:
(1) Fields can be added to any tuple; old clients will simply ignore
them. (Right now, there are some implementation limits on what
kinds of things you can put in the optional part of a tuple. I
hope to fix that, but I'd like to stress that it's not a
protocol flaw and fixing it will not require a protocol change.)
We can use this mechanism when information is added to an API
call, such as the "start_empty" parameter of the reporter calls.
(2) At connection establishment time, clients and servers exchange a
list of capability keywords.
We can use this mechanism for more complicated changes, like
introducing pipelining or removing information from API calls.
(3) New commands can be added; trying to use an unsupported command
will result in an error which can be checked and dealt with.
(4) The protocol version number can be bumped to allow graceful
refusal of old clients or servers, or to allow a client or
server to detect when it has to do things the old way.
This mechanism is a last resort, to be used when capability
keywords would be too hard to manage.
However, we (mostly I) have made the deliberate decision not to use
any of these mechanisms so far, because Subversion is still in alpha
and ra_svn is still experiencing growing pains. Unfortunately, I took
a ~6-month hiatus from significant Subversion work while a number of
people have adopted ra_svn for moderately high-profile projects under
the theory that Subversion is supposed to be "unusually stable for
alpha." This situation cannot stand for too much longer.
Right now I have some traumatic, structural error-handling changes to
make (see <http://subversion.tigris.org/issues/show_bug.cgi?id=1146>),
which would be irritating to make in a backwards-compatible fashion.
I hope to have these changes ready before 0.24. After those changes
are made, I will declare that ra_svn is ready to follow the
compatibility discipline we apply to the rest of Subversion--
tolerating a skew of at least one release.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 26 05:52:02 2003