Re: major design changes...can we

%% "Mark C. Chu-Carroll" <mcc@watson.ibm.com> writes:

>> So I can see how integrating build support into Stellation could be a
>> win. You're already commited to understanding the semantics of the
>> source tree. But with Subversion (and CVS) you lose a lot.

  mcc> Not necessarily. If you look at a system like ClearCase, they've
  mcc> kept artifact semantics out of the system, but they provided an
  mcc> integrated build mechanism which works extremely well. What they
  mcc> did was build a version of make which understands the
  mcc> repository. When clearmake is ready to issue a command, it does a
  mcc> versioned extension of that command, so that every input to the
  mcc> command is marked with a version label. If there's a file in the
  mcc> repository that was generated with the same version labels on all
  mcc> of its inputs, then it will use that as the result of the
  mcc> command; otherwise, it runs the command and caches its results.

Just as an FYI, the reason the ClearCase can do this so nicely is very
simple, and is not duplicated by any other SCM tool that I know of,
including Subversion: their "workspaces" are actual filesystems.

That is, ClearCase installs a new kind of filesystem into your kernel,
called MVFS, which allows you to interact with the repository through
normal filesystem commands. You "mount" your repository, then from
within that mounted repository you say "cat foo@@/main/1" and you're
using standard UNIX cat, but when the kernel dishes off the pathname
"foo@@/main/1" to the filesystem (MVFS), it understands that it should
break up this path and treat it as "element foo, version /main/1". This
is very cool since you can use any program to access any version of the
repository without needing to check out a temp copy, or any special
"tool-aware" variant of the program.

Anyway, leveraging this is how they get clearmake to work so well: what
happens is clearmake tells MVFS "I'm about to run a command, so start
remembering what happens". Then clearmake runs the command normally,
using normal shell/compiler/whatever invocations. MVFS is, of course,
receiving all those open(), read(), write(), etc. requests (that happen
within the repository), and it is dutifully remembering them.

Then when clearmake is done it asks MVFS to return what it remembered,
and clearmake now knows exactly what files were opened during the
invocation of the rule, what _versions_ of those files were used, etc.
ClearCase stores this data in the repository and this provides
hyper-accurate knowledge of exactly when targets are out of date,
including both prerequisites _and_ versions; knowledge that make,
relying solely on a stateless time-last-modified "database", cannot come
close to duplicating.

But, it all starts with MVFS.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org