On 1/8/07, Daniel Rall <dlr@collab.net> wrote:
> > Some comparison with the approach taken for the lock work in 1.2 might
> > be worth making.
>
> I've CC'd Ben and Fitz to get their take on the parallels, and what
> worked/didn't work during the implementation of locking.
For locking, we decided that accesses by a 1.2 libsvn_fs would
automatically create a 'locks' table of some sort, in both bdb and
fsfs, if one wasn't already present. A 'just in time' creation
situation, IIRC.
We also decided that if locks are present in the repository, it was OK
for a pre-1.2 libsvn_fs library to ignore the locks.
BTW: we went back and forth on this subject for a while, first
insisting on a format-bump that would prevent accesses from pre-1.2
libsvn_fs, but then decided that was too harsh. Our final rationale
was "hey, if you want locking to be enforced, then don't let your
users access with old libraries". I guess that same rationale can
apply to merge-tracking. I mean, really, what sysadmin lets their
users access via file:/// anyway? :-)
>
> > > > Does doing so bump either of the existing format numbers? If not,
> > > > what happens if we use a pre-1.5 client on the repository?
> > >
> > > If we go as-implemented, I'd say no. But I'd prefer to tie the merge
> > > info schema format number to the repos or FS backend format number,
> > > for simplicity's sake. The main argument I see against this route --
> > > other than code possibly needing to be written -- is that a merge info
> > > index schema change's need to bump the repos format number might be
> > > seen by users as requiring a dump/load when that is not necessary.
> >
> > I'm not sure I follow - you're worried that people may think they need
> > to dump/load because the repository format number is changing,
> ...
>
> Yup. In the past, hasn't this often meant a dump/load was necessary?
Since 1.0, our promise has always been that no dump/load would *ever*
be necessary when upgrading -- not until 2.0. Granted, we've
encouraged users to voluntarily dump/load (like, to get the svndiff1
benefit), but it's never been a requirement. All of our post-1.0
format bumps have been "auto-upgrades", never anything requiring
dump/load.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 9 16:28:08 2007