On Wed, May 31, 2006 at 12:07:39PM -0700, Steven E. Harris wrote:
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.
Yeah. Most of the fun in design, IMO, is in figuring out how you get
both functionality and simplicity -- very hard, which is the fun part!
:-)
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.
Right, sorry.
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.
Hmm, yeah, there's no way to figure this out through the user
interface. The theory is "you worry about what you want to do, we'll
worry about making it efficient". Of course, if people have their own
ideas about what will be efficient, based on other VCSes, and then
change their monotone usage to match those, they may just end up
hurting themselves... a rather subtle UI issue, and I'm not sure what
the answer is.
Anyway, though, in fact monotone does share storage between branches
whenever possible. (I'd even say "of course", since my guess is that
anyone who didn't already have scar tissue from other systems would
just assume that :-).) And branching is an O(1) operation, etc.
(It's even arguably O(0), since exactly the same work is done to
commit a revision to an old branch as to a new branch...)
Using branches also means that you always have snapshots of the whole
tree, and integrate updates made in other branches in a controlled
way -- I _think_ that means that the messiness mentioned on this
thread about keeping track of config specs just goes away?
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.
Right. You can get at this information, e.g., in a workspace you can
run:
$ (mtn automate ancestors $(cat _MTN/revision) ; mtn automate b:blah) \
| sort | uniq | mtn automate erase_ancestors address@hidden
to get the place where the workspace's branch diverged from branch
"blah" (if there have been propagates from branch blah, it is the
point of the last propagate... actually, it even does the Right Thing
whether the propagate was from blah to the current branch, or vice
versa.)
Then you can feed that into diff -r, or whatever. So the information
is totally there and accessible, though there should be a shorter way
to type that thing above :-).
I'm not sure what would be the right UI to give a more summary view
than 'diff'... maybe "status -r <...>"? Hmm, I like that idea.
(NB I also assume that at some point something more like the current
"status --brief" becomes the default status output.)
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.
Monotone tries to avoid having too much in the way of "distributed,
non-hierarchical relationships among branches". I mean, it will let
you do it, but most people's workflows don't actually inherently
involve spaghetti like that. Other DVCSes encourage such things more
than monotone, because for them each individual necessarily has lots
of branches, while in monotone branches default to shared. Monotone
basically tries to model a centralized system, just everyone has their
own copy of the center :-).
My local monotone db has 75 branches in it, but it's very very flat; I
think there are a few branch-of-branch-of-trunk, but that's about as
complicated as it gets.
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?
Well, monotone uses a single-file store, so yes, every operation that
modifies the repository does touch that one file... ;-)
The real answer to your question, though, is that monotone doesn't do
stupid things like spend time modifying its record of files that
weren't modified :-).
-- Nathaniel
smime.p7s