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.
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.
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?
3) I have worked with products that allow you to associate a comment with
a lock, and I personally think that feature can come in handy (we used it
to associate an Issue ID with a checkout). I have worked with other
products, PVCS VM, that do not let you do this when you create a lock and
have missed the feature.
Thanks
Mark
Received on Thu May 27 15:41:46 2004