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

[jc007b6093]

[JAC] Some thoughts:

> discalimer: this may not be of any particular interest to anyone! it may
> also be
> incorrect and does not necessarily represent how monotone does or will
> version
> things. it's pretty basic and may be old news.
>
> I simply jotted down these notes the other day while thinking about things
> like
> explicit directory support and the lifetime of versioned objects.
>
> I thought that I'd post it in case someone actually finds it useful or
> that it
> might provoke some interesting discussion of how things are done
> currently, and
> how they might be done in the future.

[JAC] Indeed!

>
> Cheers,
> Derek
>
> versioned objects
>
> - objects are files or directories

[JAC] or certificates? or attributes? or comments? or permissions? or ....
<add favourite metadata entity here>

>
> - objects have contents

[JAC] Objects have an GUID? (A globally and temporally unique identifier
which  never changes and is always associated with the 'quintissental'
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
(like an inode number?) I believe GUIDs are a pre-requisite to supporting
file resurrection, and also supporting cases of merging complex tree
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
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 ...

>         - 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?
[JAC] Symlinks? Hard-links? Special files? Clearcase 'kind-of' supports
symlinks - your headache may vary.

>
> - 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
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.

>         - an object's lifetime continues when it has name, location or
>           content changes
>         - the root directory exists implicitly and cannot be added,
>           renamed, moved or dropped
>         - the root directory only supports content changes
>
> - objects may be changed during their lifetime
>         - name change (rename)
>         - location change (move)
>         - content change (file's data or directory's contained objects)
>         - the root directory only allows content changes (it always
>           exists and cannot be renamed or moved)
>         - additions/deletions/renames change the directory that contains
>           the affected objects (i.e. directory content change)
>
> revisions
>
> - any single object can undergo either a lifetime change *or* a
>   name/location/content change in a single revision. i.e. changes
>   after an add change what gets added, changes before a drop are
>   essentially ignored
>
> - objects are *not* simply added or dropped, rather they are added *to*
>   or dropped *from* some containing directory. these actions change the
>   lifetime of the added or dropped object *and* change the *contents*
>   of the containing directory.
>
> questions
>
> - should "add some/path/to/some/file" automatically add the intervening
>   directories? (this seems like would probably be useful, to support
>   recursive add in particular)

[JAC] Preferably yes.

>
> - 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.

>
> - 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.

[JAC] Hope this is useful