Branko ??ibej wrote:
> Ben Collins-Sussman wrote:
> >Yes, you're right. That's how I understand it.
> >
> >A "lock", whether it be shared or not, is just a row in a table that
> >means, "this person (or persons) has exclusive rights to commit to the
> >HEAD version of this path."
> >
> >
>
> Can we now please stop letting DAV specifics drive our FS design? We've
> moved from FS functionality to LOCK/PUT/UNLOCK semantics as if there's
> no difference between the two. Basing the FS functionality on the DAV
> functionality can never be the right way to go about this, for one thing
> because DAV is stateless and web-centric and therefore has to make all
> sorts of compromises. It is *not* a good example for desigining version
> control features.
>
> I insist we should approach this the other way around: decide first
> about how we want the FS to behave, from the point of view of a
> versionable transaction-based filesystem. Then we can decide how to map
> that to DAV.
Looking at it from the svn_fs.h viewpoint is what I was trying to do.
We already export functions from svn_fs.h that allow end users to
collaborate on transactions without committing. The generic
transaction begin/modify routines do this. What we don't do is export
functionality that allows them to gain exclusive access to a path.
Why try and overload already existing functionality onto the new
locking semantics?
From another a perspective: I can imagine cases where you would want
to have multiple users work together on a transaction without holding
a lock on it. Also, I can imagine cases where you would want to hold
a lock on a path without collaborating on the transaction. Since the
two features could be used independently of one another, it seems like
they are not as related as it might appear at first.
I think you are proposing intermingling the implementation of two
distinct and parallel features. If they are both implemented
separately, you gain flexibility and decrease the complexity of
implementation.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 21 15:29:03 2004