Re: Locking: repos upgrades?

Ben Collins-Sussman <sussman@collab.net> writes:

> We have a standing promise that "no dump/loads will be necessary until
> 2.0". That means no fs schema changes.

No, that means no schema changes that cause the repository to be
incompatible with older versions of code.

> 1. I seem to recall that when we added the 'uuids' table, there was
> some magic code that instantly created the table if not present. Do
> we need to repeat that technique?

Yes. 1.1 will create the tables if they don't exist, and use them.
1.0 will simply ignore their existance.

> 2. Are we allowed to increment the 'format' file?

There's no need. If done right, we can always pretend that the
lock-nodes/lock-tokens tables were always part of the current format.
There just wasn't code to create or use them. :-)

> I'd certainly like to. Otherwise, a process using libsvn_fs 1.1 can
> create a lock, but then a process using libsvn_fs 1.0 would silently
> ignore the lock without realizing it. Does incrementing 'format'
> break our compatibility promises?

If our promise is that you can switch back and forth between 1.0 and
1.1 server versions on the same repos without badness, then yes, it
breaks them. Once the 1.1 code touches the repos, it will
soft-upgrade to the next format number, which will then cause the 1.0
code to error out.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 19 20:30:12 2004