Re: [Monotone-devel] monotone Hacking

[Hugo Cornelis]

On 9/11/07, Nathaniel Smith <address@hidden> wrote:
> > Just some ideas:
> >
> > Consider (user-visible) features F and G, implemented both in branch
> > A.  Each feature can easily constituted of multiple changesets, but I
> > assume for a moment that no single changeset is related to both F and
> > G at the same time.  In this case I would like to see exactly two
> > entries in my second level log file (and there is an entry in the
> > first level monotone log for each changeset).
>
> So perhaps it would be better to... implement F and G in branches F
> and G?  That at least reduces the proliferation of mechanisms and UI
> for them.
>
> If you mean, rather, that F and G are two general pieces of
> functionality, and over a long period of time you want to consistently
> mark all the changes that happen to touch on that functionality, then
> I guess branches aren't as ideal.
>

Mmm, well I think that branches *are* ideal for this, but they just
don't exist in the correct topology of a typical repository because of
common workflows, and common development practices, and hard
deadlines, etc etc.

One of the things I was targeting, was that with 'correct cert
attribution' of revisions in monotone, and some very clever scripting,
it might be possible to create some of these branches
semi-automatically, which afterwards should ease merging in features ?
 And, of course, these operations should maintain the feature --
changesets relationships (by annotating the constructed (plucked ?)
revisions with the necessary certs, see below).  The value I see is
that the scripting can be independent of the topology of the original
branches and revisions as created by common practices.

I guess it sounds all a bit theoretical, OTOH, easy browsing of the
several implementations of a common feature across branches is an
added value.


> At the monotone level, I guess a UI for that would be something like:
>
> -- Commit message editor --
> Increase flow through the frobulator to reduce blockage.
>
> Keywords: frob, nozzle
> -- End commit message editr --
>

I think that having the second level log in a separate file (or stream
of some sort) comes in handy when searching for certain features, and
for interfacing to external (G)UIs, e.g. to answer questions like
'Does the branch with tag Install-at-Zeemie-Cafe have a data shaper
and accelerator ?'.  Or suppose you find out that the 'high velocity
data shaper' (nozzle) has a severe bug: 'What branches are installed
at operational customer sites and have a high velocity data shaper ?'.

The way I understand what you are saying is that the shown commit
message is literally inserted in the ChangeLog cert.  Not that I would
be opposed to it, but having additional certs to tag the features
would be handy for browsing.

So in this case, two certs should be attached to the committed
revision, eg. they would show up in the monotone log next to Date: and
the other certs as:

Feature: frob
Feature: nozzle

A commit hook can check the commit message, and extract specific sets
of information from the commit message, then insert them in the second
level log.  In addition to this, after the commit has completed, the
hook adds the frob and nozzle certs to the committed revision.

Then, in the second level log file, you have short description entries like

frob: Frobulator, a tool which helps coders and server admins find and
fix memory problems
nozzle: high velocity data shaper.


Hugo


-- 
                    Hugo Cornelis Ph.D.

                  Research Imaging Center
   University of Texas Health Science Center at San Antonio
                    7703 Floyd Curl Drive
                 San Antonio, TX  78284-6240

                    Phone: 210 567 8112
                      Fax: 210 567 8152