Re: [Monotone-devel] Re: Problems with _MTN/tmp

[Joel Crisp]

Hmm.. I use a feature called "labels" or the other feature audited builds for 
that.

For those not in the know, audited builds record *every* file touched by a build (or any process launched from a build) using a 
custom shell extension (probably a wrapper on stdio, but I'm not sure of that), either by checksumming (not managed) or by clearcase 
version (managed). At the end of the build you get a complete bill of parts, telling you *exactly* what went into the build.

Clearmake is a GNU and nmake compatible make which uses clearcase version checks rather than datestamps when working out which 
dependencies are out of date

My personal belief is that people don't use the versioned file system for patent reasons - I don't think it adds any more complexity 
than say the Documentum file system or any of the linux userspace file systems (like overlay, compress, webdav, smbfs etc)

Anyway, in modern (UCM) clearcase the config spec is mostly generated 
automatically and hidden from the end-user

Joel

Johan Bolmsjö wrote:
> On Wednesday 31 May 2006 19.57, Steven E. Harris wrote:
> > Rob Schoening <address@hidden> writes:
> > > But as you alluded to, it is too clever for its own good in a lot of
> > > ways.
> > My favorite CC dynamic view/mvfs feature is the view and its config
> > spec, allowing a workspace to be a projected view across a cascade of
> > overlaid branches. That is, branches can be used to hold the minimal
> > set of changes necessary against some "parent" or "base" branch. The
> > entire repository content doesn't need to made part of this
> > "overlaying" or "child" branch; rather, one looks "through" this child
> > branch to see the rest of the base content beyond.
> >
> > Using a visual analogy, it reminds me of those transparency-based flip
> > books showing, say, human anatomy. Each sheet only contains only the
> > information different from and superimposed over the layers
> > below. Just as it's easy to hold up a given sheet and say, "This one
> > just shows the blood vessels", in ClearCase it's easy to look at a
> > branch and say, "This branch just contains my three changes to these
> > files". Branch content can thus be thought of like a patch against its
> > ordered list of "base" branches.
> >
> > Setting up views that work this way requires a particular pattern of
> > config spec rules that I won't bother detailing here. Suffice it to
> > say it's possible, and quite a pleasure to work with.
>
> I guess we are all wired differently, the config spec is the one thing that I 
> absolutely hate about clearcase. You have to be very anal about storing 
> config specs if you want to be able to recreate a build that you sent to some 
> one. "Oh, so you had a problem with this build.. Let me just dig up that 
> missing CS".
>
> Just being able to do "mtn propagate foo bar" to rebase is a blessing.
>
> /Johan
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

smime.p7s
Description: S/MIME Cryptographic Signature