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

Re: Locking design (was Re: svn commit: r9885 - trunk/notes)

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-05-27 16:43:57 CEST

Branko ibej <brane@xbc.nu> wrote on 05/27/2004 10:13:02 AM:

> Mark Phippard wrote:
> [Could you please send plain-text messages to the list? Or at least
> increase the size of the font? I find I need a magnifying glass to read
> your posts...]

Thank you for pointing that out. The messages looked like Plain Text to
me, I didn't realize it was sending HTML with a plain text font. I am
using Lotus Notes and I think I have found the proper setting to fix this.
 By the way, I set the text to wrap at line 80 (it had a default of 70).
What is the "proper" setting for that value to get the best compatability?

> > I also think that a lot of corporate users will want to see historical

> > information on locks, such as User A locked FileX at this date/time,
> > even if that lock is now long gone.
> This audit trail would more properly belong in the changes table. Unlike

> with ACLs, you don't want historic locks to apply if you check out an
> old version.

What I meant was that users might want to produce some kind of historical
report for audit purposes that contains this information. Obviously
commits are more important that locks, but some companies want to see
both. I did not mean to imply that this historical information should be
visible to, or used by Subversion itself.

> > 2) It will likely be common for Subversion to be running on a
> > different physical server than the SQL database and accessing the
> > database via Client/Server. Would it be inconceivable that some users

> > might have several Subversion servers, such as a load-balanced Apache
> > setup, all accessing the same SQL backend? I am not sure if the
> > Subversion libraries could even handle that scenario, but if it could,

> > wouldn't holding the locks in the repository layer mean that the locks

> > would be held on those single Subversion servers, instead of the
> > back-end database?
> This is not inconcievable at all. Modulo a few details regarding
> synchronizing the repository configuration files and hooks, there's no
> reason why this wouldn't work.

But would you agree that if the locks were held in the repository layer,
as opposed to the file system, that there would be a problem for this sort
of scenario? It seems to me, that if the locks are in the repository
layer, then they would not be visible to other instances of the Subversion
server. I guess that perhaps those servers could all be configured to use
a common filesystem to store the information, but that could lead to other


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 16:44:17 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.