Re: [Monotone-devel] monotone Hacking

[Hugo Cornelis]

On 9/11/07, Nathaniel Smith <address@hidden> wrote:
> On Tue, Sep 11, 2007 at 10:00:49AM -0500, Hugo Cornelis wrote:
> > Using certs, it is possible to link sets of revisions to an entry in
> > an external log file.  Then each entry in the external log file can
> > contain a global description of what happened for this set of
> > revisions.
> >
> > That way, and with the help of some shell scripts, you can support two
> > different levels of logging.  Thinking about it, I would like to see
> > the second level of logging be connected with test cases, for some of
> > my own projects.
>
> I propose that "set of revisions" ~ "branch"?  It would definitely be
> nice to have more branch metadata.
>

Yes, there is a relationship between them, I am not sure what you mean
with ~ (what is the difference between '~' and '=' ?).

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

Say for a moment that F is implemented with F1, F2,
G is implemented with G1, G2, G3.

So I have 5 entries in the current monotone log.

Then I add cert F' to F1 and F2, and add cert G' to G1, G2, G3.  In my
second level log file, I have (in short yaml notation):

F': implements feature F.
G': implements feature G.

and possibly also:

H': planned for year xxxxxxxx (or whatever)

A developer interested in features G and H can inspect/search the
second level log file, finds G' and H', (can) relate this to G1, G2,
G3, and he also sees that H' is not there yet.

The critical point to get right, is the mapping between a feature and
its cert.  I think that needs a good clear clean UI.

It is possible to map the changesets for F and G to separate branches.
 I guess the relationship with branches comes from the concept of
feature-branches and cherry-picking.

Then, what I was saying about the tests in the previous mail, could be
as follows:

My test specifications are in a separate file on my file sytem, for
each test, I currently have an entry of the form:

write: <a command>
read: <expected output>

So I simply add something like the entry:

write: <a command>
read: <expected output>
features:
  - F'
  - G'

And, in principle, I know to find the core of the code that gets
tested by a particular test... in principle, that is...  Also I can
find the explanation of the user-visible features that the test is
related to, using the second log file.


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