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

[Nathaniel Smith]

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

-- 
- Don't let your informants burn anything.
- Don't grow old.
- Be good grad students.
  -- advice of Murray B. Emeneau on the occasion of his 100th birthday