On Mon, 2002-02-11 at 12:11, Karl Fogel wrote:
> Daniel Berlin <dan@dberlin.org> writes:
> > Speaking of this, why don't we have any kind of repository version number,
> > so that we can make incompatible changes and still have backwards
> > compatiblity.
>
> This sounds like a good idea.
>
> And a fairly small patch... want to go for it?
I'm not sure tacking a version number onto such a multifarious database
is really helpful.
In this case, a repository version number wouldn't particularly help.
Let's say we run into a version 1 repository, so we know it's full of
svndiffs with BEB128 encoding. (Pretend we had version numbers all
along.) Do we continue to encode new svndiffs with BEB128, or encode
new ones with LEB128? If the former, existing repositories will never
migrate to the new format (which isn't a real problem, but only because
in this case the new format doesn't carry any important advantages); if
the latter, we'll very quickly wind up with a repository with mixed
BEB128 and LEB128 version numbers. Clearly we need a version number on
svndiffs, not on the repository. And, lo, we have one, although it's
only a single byte; the \0 in "SVN\0" is intended as a version number
(see notes/svndiff).
(In retrospect, I feel bad about putting in a one-byte version number,
even though I copied that from vcdiff, but obviously version 255 of the
format could introduce a second, longer version number just after the
SVN\377.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006