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
> > * 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Oct 29 17:36:40 2004