Hello all, I just wanted to voice support for Thomas' use case. I've seen it in real life, and I think it's rather important.
Thomas Haas wrote: >We would like to make use of certificates on file level to support the >implementation of simple workflows, ie. approval and review processes. Bruce Stephens wrote: >But I'd have though that's OK: almost all of the cases I can think of >for commenting on a file would be in the context of the rest of the >tree anyway. That doesn't match my experience. The problem seems to arise whenever a project gets input from fundamentally different domains that are loosely coupled, so that no single person can (or needs to) make statements about the entire tree. A project might comprise of code, documentation, string tables + translations, and media data (icons, textures for games, etc.). They are loosely coupled, in that one can typically change either of these independently from all others. Also, experts in one area typically cannot judge (e.g. declare 'fit for release') work from other areas. I.e., the programmer can't tell whether the Chinese translation is good (or even done). Unless he's Chinese, in which case he probably has trouble with French. And please don't let coders decide on graphical & design assets. So what one really wants in such projects is: A facility where people can mark their respective work with certain properties. (Where the graphic artists, translaters, etc. could sign off their portions of the program.) Plus a way to query which files in the current release are so marked. (Where a release engineer can find out whether the release is ready, and which parts of it.) Note that in a waterfall model everyone would simply finish their work and the 'marking' would occur only on one specific release between the phases, making everything really easy. It's just that the waterfall isn't sustainable, and these processes will always run concurrently. E.g., media assets are usually developed concurrently with the program, data must be shipped to translation several months before release, and of course during all this time coders will continue to make fixes and improvements. A suggestion, if I may: If one wants to mark a subset of a version, one could create a new manifest containing only said subset, and then attach certificates to that. I.e., one would create a new pseudo-version for the purpose of attaching information to it. In order to query the state of the current version, one would need to obtain all manifests for a given certificate, coalesce their entries, and compare them against the current manifest to determine the status of each file. This is kind of backwards from Thomas' original suggestion, but I think it work nicely with the use case. I suppose one could do both processes manually, but direct support would obviously be much nicer. From what I can see, it wouldn't require monotone to 'know' anything about these sub-tree certificates, either, except for the two new commands. Sincerely, Daniel _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
