After last week's posting about implementing opaque collections, I had
several off-list discussions in which I was convinced (read:
browbeaten) into seeing that implementing collections is not The Right
Thing to do.
To summarize some of the points that were made:
- Collections, as described in my previous email, are an unnecessarily
complex solution to the problem we need to solve.
- Yes, Apple's tools that deal with document bundles shouldn't delete
our metadata.
- We have a chicken and the egg problem when doing checkouts.
- How deep can these collections go? Where does the metadata for
subdirectories go?
- etc.
Now what?
---------
Convenience issues aside, our problems go away if we can store working
copy metadata somewhere outside of the working copy.
It was suggested that we (me) create a runtime configuration option
that, when set, would store the working copy metadata in a static
location. The directory layout of the meta data would mirror the
directory layout of the working copy. For example, in
~/.subversion/config we might have:
store-meta-data-outside-wc = true
So, if we checkout a working copy to here:
/home/fitz/svn-work/myproj/
dir1/
foo
bar
dir2/
baz
dir2subdir1/
bat
The following directories will be created to hold the wc metadata:
/home/fitz/.subversion/metadata/some-cheesy-wc-id/
dir1/
dir2/
dir2subdir1/
And, some config file (location and format TBD) will contain a lookup
dictionary something like this:
KEY VALUE
/home/fitz/svn-work/myproj =
(http://svn.myserver.com/repos/trunk/path/to/myproj, some-cheesy-wc-id)
So, when svn is invoked in a working copy, take $CWD as path, and
using it as a key, load up the above-mentioned table, and try to get a
value from a for that key. If we get null back, remove the last path
element and try to get a value again. Continue walking up the FS tree
until we get a value returned. If we get null all the way up, we're
not in a working copy. (Note that this mechanism handles nested working
copies from diverse repositories).
This, however, means that if you move a Subversion working copy,
Subversion will not be able to find its metadata. We would need to
have some way to tell the svn client that we've moved a working copy
(something like 'svn move-wc /from/this/path /to/this/path).
With our meta-data out of the way, bundled documents are just like any
other directory structure to Subversion. And our lookup dictionary
means that we don't need to worry about drive letters on
win32. Joy. Oh, and you don't have to resort to bizarre 'find'
incantations when hunting for stuff in your working copies. :)
You may notice that the filesystem path above points to a tuple
containing the Base URI of the wc as well as the wc meta-data ID. This
will actually allow our client the ability to enumerate through
checked out working copies and map them easily to repositories
(Although can't we derive that from a wc's metadata?). Bill Tutt might
want to explain more about that. :)
Comments?
-Fitz
PS Thanks to Bill, Sander, and Ben for all their help (and occasional abuse).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 29 07:16:23 2002