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

[Steven E. Harris]

Nathaniel Smith <address@hidden> writes:

> Hmm, my understanding is that different people have different
> experiences here :-).

True. It's not necessarily easy to understand, but once you get it...
Many a great idea die on that vine.

> What does a config spec give you that just making a branch doesn't?

I assume your contrasting a config spec with a branch refers to making
a branch /in monotone/, as in ClearCase branches and config specs are
not exclusionary or redundant concepts.

> E.g., I can have a branch that only modifies a few files as compared
> to its parent branch,

Maybe the allure in ClearCase appeals to "efficiency": There's the
sense that we're not "copying" those underlying versions from one
branch to another, just for the sake of making a few changes to the
new branch. I put copying in quotes because some VCSs really do make
separate copies of the files or versions that remain logically common
between the two branches, or at least mark the common files somehow to
indicate membership in both branches. That makes branching an O(n)
operation on n constituent files in the repository. ClearCase's
branches (coupled with suitable config spec rules) make it obvious
that one is both recording and storing "only these few additions or
superimpositions over all that stuff over there". Again, they seem
patch-like in character.

Perhaps monotone already handles branches the same way, only marking
for branch membership what differs from its ancestry. I can't quite
figure it out through the user interface, though perhaps having
monotone-viz available here would be revealing.

> I can see what files those are by doing a diff against the latest
> branchpoint, and so on...

This sounds like several steps would be involved: figure out the
proper revision ID for the branch point, then feed that to "mtn diff
-r", then try to pick the file names out of the diff output. Is there
some more succinct way to ask, "What files have been changed on this
branch?" Perhaps more importantly, "What files have been changed on
this branch since the last sync (propagate?) with this other branch?"

Those are the questions we wanted to be able to answer frequently and
easily with the ClearCase scheme I described.

> is it more convenient somehow, does it give you more features?

I'm not sure it allows me to do more that is actually safe or
advisable in practice. ClearCase is much more of a toolkit upon which
one can build policy and working models, and in that sense it's too
powerful (or lax, if you prefer) in its base form. We put a fair
amount of work into applying its features to enforce constraints, many
of which bring us right back to what monotone already does today.

Also, we were using ClearCase in a centralized scheme, and hence faced
none of the problems associated with distributed, non-hierarchical
relationships among branches. That is, branches had a single "parent"
branch against which they would sync, forming a large tree, stable and
public near the trunk, unstable and private at the leaves.

Given too that we had this centralized scheme, there's an admirable
elegance in a system that conserves storage resources. Creating a new
branch doesn't imply touching all the files in the repository, so
there's less concern over the cost of creating small branches that
only need to touch a few files. Does monotone work the same way?

> If you let us know, maybe we can steal the ideas :-).

Fortunately, you probably already have all the good ones.

-- 
Steven E. Harris