Re: [Monotone-devel] Re: Certificates for files

[Daniel Vogelheim]

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