Having had the holiday to ponder the responses to the last proposal, I
began to feel like we were just barking up the wrong tree. So, based on
a discussion I just had with sussman and cmpilato, I'm going to propose
a radically different solution to this that (I think) falls much more in
line with Peter Lundblad's suggestion that I kept (stupidly)
pooh-poohing as inadequate (Sorry Peter).
So here we go.
There are several limitations that we must overcome when designing
locking in fs_fs:
1. We have to handle UTF8 path names: not all filesystems do this.
2. We have to accomodate case-sensitive/case-preserving filesystems.
3. We have to worry about path length limits (262 bytes in some cases).
Our primary use cases for the locking system are:
0. Lock path FOO.
1. Is path FOO locked?
2. Quickly return all locks BELOW path FOO.
The new design radically changes the locks directory and leaves the
lock-tokens directory fundamentally unchanged.
The locks directory will no longer be a tree mirroring the filesystem
layout, but instead, it will be a single directory (or spread across a
series of 10, 100, or 1000 directories) containing files that will be
named according to a monotonically increasing integer (stored in the
revs equivalent of the db/current file.
Each file will represent a path component (or "node")--whether the path
component corresponds to a directory or a file.
Each node will contain, on the first line, "FILE" if the node represents
a file, or "DIR" if the node represents a directory.
If the node is a directory, the second through n lines will contain a
serialized hash of entries, where the hash key is the name of the child
component, and the corresponding value is the integer of the filename
where the node's lock is stored.
If the node is a file, the second through n lines will contain a
serialized hash representing the svn_lock_t that is held on the file.
So, for example (using a simplified file format), if we lock the file at
path foo/bar/baz.c, the following files will be created in the locks
directory:
Note that file '0' *must* correspond to the root directory, so it will
be created by default, and it's name will always be '/'.
0:
"DIR"
HASH_BEGIN
"foo" -> 1
HASH_END
1:
"DIR"
HASH_BEGIN
"bar" -> 2
HASH_END
2:
"FILE"
<<<lock representation here>>>
This should address all of the wonkiness WRT path lengths and fs
encodings since everything gets encapsulated in these little
"entries-type" files.
Thotz?
Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 4 21:55:13 2005