My opinion--not a terribly strong one, as my opinions go--is that we
should not support lock-null resources in libsvn_fs, even if that
requires an ugly hack in the autoversioning code. My reasoning comes
from the following principles:
* No unnecessary infrastructure: If we are not going to support
lock-null resources in the Subversion client, we do not want any
complexity from supporting it in the FS. (And if the W3C has decided
that lock-null resources are a bad idea after all, we should probably
follow their lead.) At first glance, it may appear like more complexity
*not* to support lock-null resources in the FS, but I don't think that's
true; if we have lock-null resources, then we need a way of discovering
them (merging locks into depth-1 directory listings, for instance) and
we need to check for them when we add a file or directory.
* Scalable performance: Supporting lock-null resources in the FS means
we need to be able to do depth-1 enumerations of the locks in a
directory. In the BDB back end, the most natural representation does
not allow that to be implemented in a very scalable fashion.
(Mitigating counterargument: in real life, you're not going to get huge
numbers of active locks in a repository unless you have people abusing
recursive locks as ACLs. So I'm not sure I care.)
* Segregation of complexity: auto-versioning is a non-core feature of
Subversion. So, to the greatest extent possible, any requirements it
introduces should be handled in the auto-versioning code, not in the
core. If this means we implement the deprecated lock-null feature by
guessing at what clients are going to do, so be it. (We were prepared
to simply not support lock-null resources under DAV until we found some
clients which cared about it; why do we now have cold feet about only
support it for file creation, when the W3C is telling us that's all it
gets used for?) I'll note that if we do want to support LOCK; MKCOL and
LOCK; COPY, we can probably do that by tampering with the
auto-versioning parts of MKCOL and COPY, which still restricts the
complexity to the auto-versioning code.
All that said, having half-assed support for lock-null resources in
libsvn_fs is perhaps the globally easiest thing to do, which is my
opinion isn't a strong one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 19 22:53:43 2005