monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Re: user-friendly hash formats, redux


From: John S. Yates, Jr.
Subject: [Monotone-devel] Re: Re: user-friendly hash formats, redux
Date: Tue, 7 Dec 2004 16:57:07 -0500

"Richard Levitte - VMS Whacker" <address@hidden> wrote in message
>
> lsackette> diff blah.c/my_branch/3 blah.c/your_branch/latest
>
> I'm sorry, but *GAH!*  Is that how it looks working with CC?  What if
> I want to make the difference between the file foo/bar/1 and
> bar/foo/3, are those considered files with numeric names inside two
> sub-levels of directories, or version 1 of the file foo in branch bar
> and version 3 of the file bar in branch foo?
>
> For me, a syntax of that sort would be a definite turn-off...

ClearCase inherited this syntax from Apollo's DSEE.  In the Apollo file
system there was not a canned collection of file system types (normal,
directory, block, char), but rather a type stamp UID in the VTOCE (more
or less an inode).  A system database mapped these type stamp UIDs to
"trait handlers" (implemented as shared libraries).  The two very most
important traits were:

 "directory-ness" - ability to map names to UIDs
 "stream-ness"    - ability to support open, close, read, write, etc

If path resolution encountered a VTOCE that was stamped as "native
directory" the lookup was performed by the directory implementation
bound into the kernel.  If the type stamp was not "native directory"
then the type stamp / UID was looked up in the database to see if
that file type supported "directory-ness".  If so then the relevant
shared library was demand loaded and the residual path was passed to
the associated lookup method to continue resolution.

Given this framework, any file system container type could be exposed
as a directory within the normal file system namespace.  Two important
clients of this mechanism were compound executables (single images that
were really archive files with sections for multiple distinct machine
architectures) and DSEE history files.  Both DSEE and ClearCase use a
model of named branches and numbered versions.  Thus

  /home/jyates/my-sandbox/some-component/foo.c/my-feature/3

is a perfectly fine path that I could pass to the file system on an
open and expect to object a stream back in return.

The ClearCase implementation strives to provide the same experience
though it can only do so on ClearCase MVFS (Multi Version File System)
volumes.

/john







reply via email to

[Prev in Thread] Current Thread [Next in Thread]