[Monotone-devel] database schema questions

[Derek Scherger]

In messing around with the lua hooks I was wondering about where/how to get filenames for 
merge information and this lead me into a closer look at the schema to see how things are 
stored. I've also done a bunch of testing with very simple databases (described in another 
post) and I think I'm starting understand things but, yet again, I do have a few questions. ;)

Does the files table contain the heads of various files, and the files_delta table contain 
deltas from the head backwards to each previous parent version? I think this is 
conceptually similar to how rcs stores files (reverse deltas), and the reverse of how sccs 
does (or did). Presumably manifests and manifest_deltas work similarly.

It seems that branch certs are "sticky" in that they will get added to successive 
manifests that descend from a parent in the branch. Is this done purely with the branch 
setting in the MT/options file?

Since files are stored as nothing but an id and some data they really don't have a name at 
all and some name is provided to the data by evey manifest that includes it. Adding a file 
under the same name to two different (otherwise empty) branches creates only one file and 
one manifest, and the manifest has 2 different branch certs. Adding the same file under a 
different name to yet another empty branch creates another manifest (because of the name 
difference) that has the file's version listed under the new name.

Given the previous paragraph would it make some sense to store manifests as a table with 
columns like manifest_id, file_id and file_name? This would allow any file to get all of 
the names it is known by and a list of all the manifests it is part of very easily. This 
internal representation would still be supported by an external representation as a 
regular file. manifest_deltas could similarly be stored with file_id and file_name and 
something like an operation (add, drop, rename, change), I guess both old and new file id 
and name would be required here actually.

I do see that this represents some additional complexity in that files and manifests are 
then stored and treated differently. But would there be some advantage to making file 
names easily available? I have the impression that getting a file name is somewhat 
involved in terms of unpacking manifests and constructing the associated maps. I'm also 
wondering whether a manifest merge under this representation would be possible as a simple 
sql union of two other manifests.

Monotone seems to represent simplicity, minimalism and complexity all at the same time. It 
feels like it probably provides comparable or even more functionality than either 
subversion or tla do but in a *much* simpler and cleaner way. Maybe this is what I'm 
finding so interesting about it.

--
Cheers,
Derek