[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-10-29 17:35:57 CEST

On Fri, 2004-10-29 at 02:48, Branko Èibej wrote:
> > * Branko has also argued that a database implementation of the
> > repository would want to store the locks in the database. (But he
> > also thinks you'd want to store the hooks and everything else in
> > there too, so that argument is predicated on a disagreement with
> > the current repository design.)

> Huh? Did I say that? I may have theorised that a backend using a
> /relational/ database would want to put everythong in the database,
> sure. That doesn't mean I don't agree with the current separation used
> by the BDB and FSFS back-ends.

In http://svn.haxx.se/dev/archive-2004-05/1188.shtml you wrote:

        On a related note, I'm beginning to wonder why we have a
        separate filesystem and repository layer. Taking stuff out of
        the filesystem and putting it in the repos to keep the
        filesystem "clean" is weird, because the definition of "clean"
        seems to shift with the wind (for example, I suggested
        implementing revprop indexes in the repos layer, and ghudson
        objected. Then I suggested implementing locks in the FS, and
        ghudson objected... :-) And we keep duplicating APIs all over
        the place because of this dichotomy. And arguing about where
        core FS features such as ACLs and locking should go.

Actually, I'm glad I looked that message up, because it contained an
argument for locks-in-the-FS which I didn't list: data stored in the
repos layer hasn't so far referred to FS paths, so storing locks there
would break with precedent. (Although the path-based authz file is an
existing example of data managed external to the FS which refers to FS
paths. And had there been more design review of mod_authz_svn before it
was added to our release, I would have argued that the authz file should
have lived in a fixed location within the repository, rather than the
current practice where you specify its pathname in httpd.conf.)

> > * The data currently managed by libsvn_fs is versioned, so adding
> > locks would be breaking precedent.

> Revprops aren't versioned.
> (A mistake IMHO, but that's another story entirely and I certainly
> wouldn't want to try to fix it before 2.0)

Touche. (Actually, I have an idea in my head for making revprops at
least weakly versioned without breaking compatibility. Essentially,
turn the value of a revprop into an ordered list of <author, date,
value> tuples. Setting a revprop appends to the list; getting a revprop
retrieves the most recent value; we add new protocol requests to
retrieve revprops with the historical data. There's a repository-format
transition issue to worry about, but I think it's solvable. But this is
totally off-topic.)

> > * The data currently managed by libsvn_fs is dumped and loaded, so
> > adding locks would be breaking precedent.
> >
> The changes table isn't...

The changes table isn't data; it's an index. (And one could argue that
since it's used to determine what to dump, it is dumped.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 29 17:36:40 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.