For my own part, I'm backing out of this change altogether. Once I
started coding it, I realized some things that make this whole idea a
major turn-off:
- I can't think of a good way to guarantee atomicity across the
upgrades of the filesystem and the repository. And what in the
world do we do if a repository claims a 1.1 format number but the
filesystem has a 1.2 one?
- The number of places in which code would need to either check version
numbers before allowing a piece of functionality, or trap and
specially handle an SVN_ERR_FEATURE_NOT_IMPLEMENTED error, is
much larger than I expected.
- I'm not a fan of the resulting precedent and maintenance burden.
Will we have to maintain these conditional behaviors through 1.3,
1.4, ... ? I suppose at 2.0 we can have a clean slate again,
perhaps?
- As was previously stated, all of this is for the benefit of teams
using ra_local, which I contend is the one type of team where
differing version numbers are *least* likely to happen (thinking
of the company-wide "you shall use version X.Y.Z of tool FOO"
type stuff).
I suppose you can summarize that list as, "This is hard, and only gets
harder over time."
It was suggested previously that we simply auto-upgrade the repository
without bumping the format number. The result, of course, is that 1.2
and 1.1 clients can work on a pre-1.2-turned-1.2 repository without
any "yer client cain't support this 'positurry" errors. But as the
foremost goal of the locking functionality is the prevention of wasted
time, I cannot support this idea either. I'd be pretty upset if I
locked a binary file to make a slew of edits and someone else came
along and committed atop it anyway (making me out of date) simply
because their client didn't know any better.
I am currently compelled (by reasons of having some semblance of
sanity as a personal goal) to bail on this task, and further to
suggest that we stick with the auto-upgrade mechanism as-is. The
network is our compatibility layer -- if you choose not to use it,
that's your own concern.
Branko Čibej <brane@xbc.nu> writes:
> Tobias Ringström wrote:
>
> > Ben Collins-Sussman wrote:
> >
> >> On Mar 28, 2005, at 5:07 PM, C. Michael Pilato wrote:
> >>
> >>> Question: How much do we care about repository sanity during this
> >>> upgrade? I started to code these new APIs, but couldn't decide if I
> >>> needed to reproduce the whole 'exclusive lock' code ala
> >>> svn_repos_recover2(), and, if so, how to deal with the same scenario
> >>> down in the svn_fs libraries (which, in theory, could be upgraded
> >>> independently of the svn_repos wrapper).
> >>
> >>
> >> I think that svn_repos_upgrade() should share the same "waiting for
> >> exclusive repository lock" logic that svn_repos_recover() uses.
> >
> >
> > It would be nice to be able to avoid the exclusive repository lock
> > because it's quite disruptive, and it makes it harder to upgrade
> > busy repositories online.
> >
> > My knowledge of the details of the locking implementation is a
> > little fuzzy, but it is my understanding that the upgrade only adds
> > new files/DBs (i.e. does not modify existing ones) and changes the
> > format file. If so, how about creating the new locking files/DBs and
> > then, as a last step, move a new format file in place of the old one
> > to atomically upgrade the repository. If we care about the risk of
> > two simultaneous upgrades (which I think we should), it should be
> > possible to create a write lock on the format file before starting
> > the upgrade.
>
>
> Creating those new tables should take close to no time at all. I doubt
> there's a repository that's so busy that you can't afford to lock it
> for one second.
>
> -- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 18:10:57 2005