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

Re: Locking server implementation: libsvn_repos or libsvn_fs

From: Martin Furter <mf_at_rola.ch>
Date: 2004-10-29 22:54:22 CEST

On Fri, 29 Oct 2004, Mark Benedetto King wrote:

> On Fri, Oct 29, 2004 at 12:18:14PM -0400, Greg Hudson wrote:
> > On Fri, 2004-10-29 at 12:01, John Peacock wrote:
> > > Just so everyone is on the same page, that means when recovering from a
> > > backup/dumpfile, all locks are lost and cannot be recovered/recreated.
> >
> > If we implement locks in libsvn_repos, and are a little careful about
> > it, we can probably just tell people to back up the locks table and
> > restore it, much like the rest of the repository data (hooks, etc.).
> >
> > If we implement them in libsvn_fs, we probably want to think hard about
> > being able to dump them, even if the default is to discard them on load.
> >
> > > Any WC's with lock tokens will have to gracefully handle that
> > > inconsistency and the server will have to ignore lock releases for
> > > unknown locks.
> >
> > To the WC, the server losing the lock table would look just like the
> > lock being forcibly broken, so nothing new there.
> >
>
> Nothing new, but that doesn't necessarily mean that we shouldn't
> include the locks in the dump, and let the administrator choose
> whether or not to restore them at recovery time.

I'd like to do dumps of the locks the same way i do it for the revisions
in my repos in a post-commit hook.
If I understood that right, a lock/unlock is not a commit and the commit
hooks don't get called.
So it would be nice to have dumplocks/loadlocks commands which I could use
in post-lock/post-unlock hooks for backuping the locks.

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 29 22:57:00 2004

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.