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...]
> Ben Collins-Sussman <sussman@collab.net> wrote on 05/26/2004 04:59:27 PM:
>
> >
> > So we're faced with two choices here:
> >
> > 1. create a locks-table API in svn_fs.h, have svn_repos.h use it.
> >
> > - this means one fs backend would use a BDB table, and the other fs
> > backend would have to implement the table either using a flat-file or a
> > 'mirror' of locked repository paths in real filesystem space.
> >
> > 2. create a locks-tabel API in svn_repos.h
> >
> > - libsvn_repos absolutely cannot depend on BDB, so it means that it
> > would need to implement the table either with a flat-file or a mirror of
> > locked repos paths in real filesystem space.
> >
> > Either way, it looks like the "non BDB" option is going to have to be
> > implemented, and real energy will be spent making sure it's reasonably
> > scalable. Given that, option #2 seems better to me, just because it's
> > nice to have shared/factorized code. And if we plan to add other fs
> > backends someday (like SQL), this option becomes even more attractive.
> >
>
> I am thinking ahead to a SQL implementation and had a few thoughts on
> this:
>
> 1) SQL implementations are going to tend to be desired by corporate
> users, and those are the same users that are going to want to use
> locks heavily, including for text files. I think that being able to
> see what locks are currently held, and by whom, would be an important
> feature. If this information were in a SQL table(s) that would be
> relatively easy for those users to implement.
Yes, that's another good argument, and I was thinking along the same
lines. If you've shelled out many M€'s for your huge Oracle
infrastructure, and you perhaps paid someone to implement an Oracle
back-end for Subversion, you'll definitely want to keep _everything_ in
the database.
> 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.
> 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.
---------------------------------------------------------------------
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:15:18 2004