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

[Nathaniel Smith]

On Wed, May 31, 2006 at 04:43:18PM -0700, Rob Schoening wrote:
>    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.

Yeah.  Hard to do much about this without the massive pain associated
with writing and maintaining a portable filesystem interface, though.

Which isn't to say that people shouldn't go ahead and write one, but
the portability issues and the user-uptake issues (a lot of people
refuse to deal with the setup hassle) mean that it's probably best
approached like a GUI interface.  (Which it is, just without much "G"
:-).)

>    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.

Yeah.  One of the reasons for trying to make sure that 'mtn automate'
is as convenient as possible for shell-scripting...

>    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"

Unfortunately, I think you overestimate what using sqlite buys us ---
SQL is great for ad-hoc queries that are easily expressed in terms of
the tuple representation you choose.  For monotone, that mostly means
things like selecting by certs (which is, in fact, quite useful!), and
some amount of revision graph stuff (though most of it we have to do
by hand, SQL not being really known for its elegant handling of graph
structures).

The actual versioned data, like the code chunk you refer to, is stored
in heavily heavily compressed form, not really accessible to such
querying.

Which isn't to say that that particular query can't be supported,
just, it would be a cool feature to add, not something one gets for
free.

(Well, "annotate" may give that particular one already...)

>    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.

Have you tried 'mtn show_conflicts'?

-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music