[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: locking a file renders repos unusable with older clients

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-03-30 17:19:02 CEST

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,

   - 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.