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

[Rob Schoening]

I got a laugh about the comment that everyone seems to moan about clearcase until they aren't using it.   Very true.  It is powerful, but can be a real pain.

 

But to the point of "what CC-style features would be nice to see in monotone?"

 

One of the best features of CC is the ability to simply and easily write scripts that dig into the VOB (repository).

 

You can append @<branch>/<version> style selectors to the end of the file and standard tools (diff, vi, etc.) will open the proper version, regardless of what's in the current view and/or how the configspec is written.

 

Thus it's possible to write shell-based reports of just about anything in the repository using find, diff, grep, sed, awk and friends.

 

It's not that it can't be done using other VCS tools (that aren't hooked into the kernel as filesystems), but it's just harder and more cumbersome since you typically must work with files that aren't in the workspace as streams (as in 'mtn cat'), not files.

 

Actually, with the repository in sqllite, it seems to me that this is one area where monotone will eventually excel: being able to create and run ad-hoc reports against the repository natively:

 

"Show me on what branches/revisions the following code chunk first appeared"

 

Another one that might be possible today (though I am not aware of how) is being able to see a report of what various operations (propagate, etc.) would do without actually doing them. 

 

But as Nathanial has suggested it is probably best to keep focus on the minimal stable set of features for the core product.  Most of this other stuff can be implemented with wrappers and hooks of various kinds.

 

RS

 

On 5/31/06, Joel Crisp <address@hidden> wrote:

I think that one feature of config specs which hasn't been mentioned yet is 'lazy branching'

In other words, I have a personal branch which shadows a team integration branch which shadows the main branch.

If I checkout a file which only exists on the main branch, it automatically creates branched versions of that file on the team and
personal branches.

A rule like (sorry, can't remember the exact syntax and I'm at home atm):

* /main/team/personal/CHECKEDOUT
* /main/team/LATEST
* /main/LATEST
* mkbranch /main/team/personal

would automatically make a branch on /main/team/personal whenever I check a file out

This is some of the magic of config specs ;-)

Oh, and one other neat feature is lspriv -recurse, which lists all the files in the current view (workspace) which are *not* under
version control.

Clearcase also has an _expression_ language for selecting versions (think SQL for configuration management) which is highly flexible,
and which can be combined with the find command....kinda like monotone selectors on speed....

Most clearcase commands also take the -short and -long options to give easy control over the volume of output. They also (I think
we've spoken about this before) take the -fmt option which is like printf for CM systems.

Unfortunately the clearcase version tree viewer is slooooow compared to monotree, or the other viewer. Obsoleting branches helps,
but on very large trees some way of displaying just the most recent branches while you fill in the rest in the background would be
useful.

Joel


Nathaniel Smith wrote:
> 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
>


_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel