Re: [Monotone-devel] some basic notes on object versioning

[Derek Scherger]

address@hidden wrote:
>>- objects have contents
> 
> [JAC] Objects have an GUID? (A globally and temporally unique identifier
> which  never changes and is always associated with the 'quintissental'

obviously my thoughts are rather skewed by monotone, which uses the SHA1
hash of a file as it's version and currently does not have another
concept of GUID.

> object). For example, a directory may have content changes, and be moved
> or renamed in the tree, but it is always associated with it's unique key

which seem to me to be two distinct types of change (content and
location). note that location changes coincide with content changes to
the directories involved in a rename.

> (like an inode number?) I believe GUIDs are a pre-requisite to supporting
> file resurrection, and also supporting cases of merging complex tree

in fact monotone uses tids (transient identifiers) to represent things
during merges and is able to deal rather well with complex tree
rearrangements. better than any other system i've used, which isn't
really saying much unfortunately, since most old-school version control
systems hardly deal with renames at all. but from what I've seen of
perforce (about a months worth) I think monotone has it beat rather
handily in terms of rename support at least.

> changes. Note that using the directory/file paradigm in Clearcase with UCM
> and trying to merge two streams where one stream contains a lot of files
> which have been both re-named and edited (a classic case in Java) normally
> causes Clearcase to get _really_ messed up. Partly this is due to trying

and from what I've seen of monotone its able to handle this *really*
well, so kudos to graydon and njs who seem to be the responsible parties.

> to merge-in-working-copy, as you end up with a file being re-named and
> then the merge tool trying to merge changes into the original name (which
> no longer exists...) and things break down very quickly into primordial
> soup ...

I'm curious actually, does anyone get merge into working copy (during an
update) right? again, from what I've seen, monotone seems to do really
well here and has "upped the bar" considerably.

> 
> 
>>        - files contain data and may be empty
>>        - directories contain other objects, by name,
>>          and may also be empty
> 
> 
> [JAC] Name or GUID? Or a mapping of name to GUID?

I'm thinking name is what monotone might want... purely in terms of
something to consider as the directory's contents so that it can
calculate a somewhat meaningful sha1 hash for the directory's version.

> [JAC] Symlinks? Hard-links? Special files? Clearcase 'kind-of' supports
> symlinks - your headache may vary.

yeah, all that... ;) monotone also tries fairly hard to be
cross-platform, which makes some of these rather difficult. the
attributes facility is rather raw, but flexible depending on your
creativity.

>>- objects have attributes
>>        - eg. rwx permissions, binary type, etc.
>>
>>- objects have versions
>>        - computed as the sha1 hash over their contents
>>        - a directory's contents may simply be represented
>>          by the names of the objects it contains
>>          (newline separated)
> 
> 
> [JAC] Names and/or GUIDs?
> 
> 
>>- objects have names
>>        - their name within their containing directory, i.e. basename(1)
>>        - names may change (i.e. rename)
>>
>>- objects have locations
>>        - their full path name with / separators exclusive of their name,
>>          i.e. dirname(1)
>>        - locations may change (i.e. move)
>>
>>- objects have lifetimes
>>        - an object's lifetime begins when it is added to its
>>          containing directory (birth)
>>        - an object's lifetime ends when the object is dropped
>>          from its containing directory (death)
> 
> 
> [JAC] I would disagree with this. Objects may have multiple names, and to

yeah, and multiple names and locations for the same file version (sha1)
are supported too.

> support resurrection it is necessary to be able to identify an object
> independently of the containing directory. This is how Clearcase supports
> resurrection (by giving all objects an GUID). Examining file system
> convention, the directory tree is just a one method of looking up files -
> the inode number being the other. The file's _real_ (unique) identity is
> given by the inode number and there may be multiple directory entries in
> multiple directories all referring to the same inode.

and if there are no inodes referring to the file it's gone, since the
filesystem doesn't store history. a monotone db will certainly continue
to contain the various file versions, identified by their sha1 hashes,
even when these hashes are not mapped into some manifest in the current
revisions.

>>- should "drop some/path/to/some/file" automatically drop the intervening
>>  directories? if they're empty? (this seems like it would probably be
>>  somewhat less useful!)
> 
> 
> [JAC] Optionally yes. However there are cases where checkin of an empty
> directory can be useful.

it's not so much checkin of an empty directory (which would have the
da39... sha1 version associated with empty blobs) but rather what to do
when deleting a file causes a directory to become empty. in filesystem
terms directories don't magically disappear when they become empty, and
the probably shouldn't in monotone either. purely from the perspective
of preserving symmetry recursive add could be paired with
inverse-recursive drop. this would probably be bad news in general though.

>>- treating move and rename as different is somewhat questionable,
>>  although move seems like a somewhat better representation than
>>  rename if only one is used
> 
> 
> [JAC] In a file system, the difference is often one of atomicity. Rename
> is atomic, move may not be. For example, under windows re-name on the same
> file system is atomic, move across file systems boundaries is not. Not
> sure what this statement contributes to the discussion.

yeah, either way is atomic in terms of commit. I was just wondering
about the name/location distinction.

> 
> [JAC] Hope this is useful
> 

sure, thanks!

Cheers,
Derek