On 9/11/07, Nathaniel Smith <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel