"C. Michael Pilato" <cmpilato@collab.net> writes:
> Tobias Ringström <tobias@ringstrom.mine.nu> writes:
>
> > Why do you need to upgrade the repository format? I thought the
> > repository format was for the basic structure of the repository,
> > i.e. that it has a hooks dir, a db dir, etc, and that the fs
> > format/revision was for the stuff inside the db dir. Since the
> > locking changes are all inside the db dir, and the repository is
> > unchanged except for a few extra hook templates which don't really
> > have to be added by an upgrade, IMHO. What am I missing?
>
> We did add hooks in 1.2.
>
> And we didn't have an FS version number before 1.2, which means the
> repository one is the only one available to pre-1.2 libraries for
> doing compat checks.
>
> But: See kfogel's forthcoming post about the new stance of the
> CollabNet Chicago Four(tm) on this issue.
Er, I guess that would be me.
I'm familiar with this discussion, since it started before I went away
on my brief sojourn in the Crab Nebula. I won't pretend to have read
the entire thread since then (sorry), but it's been summarized to me,
so I think I grok the current State Of The Onion, namely, that we
haven't decided what to do yet :-).
First, let's all please not get confused by the introduction of the
new FS Format Number. That was mainly for future changes. The
question before us is whether and/or when to bump the *Repository*
Format Number, so that old clients can be at least minimally sensitive
to the presence of locking.
The four overall choices seem to be:
1. Don't bump it.
Advantages: Simplicity (the locking tables/trees already get
added automatically, so everything will work out of the box).
The repository continues to work even if you downgrade the
server code. Sharing access among file:// clients that are both
pre- and post-1.2 would work smoothly -- no upgrades would be
required.
Disadvantages: Downgrading the server code after having used the
locking features means that the lock information will be
ignored. Also, sharing file:// access among pre- and post-1.2
clients would mean that the former would simply *ignore* locks.
We would have to warn about this in the release notes. Note
that this problem ONLY exists with teams using file:// access.
The networked RA layers do not have this disadvantage.
2. Bump it unconditionally.
Advantages: Simplicity; everything still works out of the box.
Disadvantages: Downgrading server code to pre-1.2 is now
impossible (well, you can make it work, but it would be an
annoying hassle). Forces everyone sharing file:// access to
upgrade at once, whether or not the team is even using locking.
3. Bump it the first time a locking feature is used.
Advantages: No one pays a price until locking is first used;
fully automated, everything still works out of the box.
Disadvantages: Not so simple to code. Also, using locking
becomes this weird boundary event that will have unexpected side
effects ("What, you mean now we can't downgrade?"). People
sharing file:// access would have a particularly rough time: all
of a sudden, pre-1.2 users would stop being able to access the
repository, even though they had been using it together with 1.2
users just fine before then.
4. Insist 'svnadmin upgrade' be run before locking can be used.
Advantages: The incompatibility step becomes a conscious act.
Disadvantages: The big 1.2 feature doesn't even work unless you
run this new command you've never heard of before? Whoa. And
again, once you run it, the code cannot be downgraded, and
file:// users must all be upgraded.
(There are some variations on these plans, e.g., involving requiring
that a 'pre-lock' hook exist, like pre-revprop-change, before any
locking operations can happen, but I won't go into the details here.)
We in Chicago are unanimously advocating solution (1).
Here's why:
Its advantages are obvious: everything works out of the box, you can
upgrade and downgrade with abandon, and we certainly won't *cause* any
gratuitous incompatibilities.
With this solution, teams currently doing file:// access can continue
working without doing anything different. If they want locking, they
just have to upgrade together. Now, there is an outside possibility
that one of them will upgrade to 1.2, set a lock, go do three weeks of
work on the file, and then be shocked when it turns out a pre-1.2
file:// client ignored the lock and made commits to the file during
that time. But really, how likely is this, and how much should we
inconvenience other users to prevent it? I mean, someone could set a
lock, get on a three-week airplane flight, and then someone else could
break the lock behind their back and commit anyway, all with post-1.2
clients. Subversion can never address all these situations, nor need
it try.
Regarding the disadvantages:
For those who never use locking at all, there are no disadvantages.
(1) is clearly the best option for them.
For those who do use locking, the disadvantages are still fairly
minor. Over the networked RA layers, locking will be enforced as long
as the server side is 1.2 or higher, plus the above caveats about
file:// access. If the server side is downgraded, well, of course the
locks will be ignored, but this is no tragedy. Locks are
fundamentally advisory anyway. It would be a mistake to complicate
things for everyone else merely in order to prevent advisory locks
from being ignored for those who downgrade to a version of Subversion
that never supported them in the first place. There's no reason to
shut down the farm just because they start using locks but then
downgrade. The release notes will make it clear that locking features
require 1.2.
Meanwhile, solutions (2), (3), and (4) all penalize the majority for
the sake of the minority. While this is sometimes desirable -- say,
when the penalty for the minority would be death, while the penalty
for the majority would merely be a stubbed toe -- in this case the
minority's penalty is not particularly severe anyway, and does not
warrant imposing complicated and/or unexpected behaviors on everyone
else.
If we agree on this, I'll just undo the effects of r13384/r13366, and
everything will go back to the way it was, and we won't get any more
angry mails from file:// users asking why they're being forced to
upgrade.
Is it consensus?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 31 00:25:31 2005