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

[Nathaniel Smith]

On Mon, Sep 12, 2005 at 10:00:12PM +0200, Thomas Haas wrote:
> It is a semantical thing to me. I understand that certificates in
> monotone today make a statement about a certain state (=revision) of the
> whole tree. Monotone does not have a notion of a statement about a
> subset of a tree. (Note: this is not a critic towards monotone, just a
> fact.)

Well, it depends on which way you squint at it.  You want to have a
way to get monotone to store certs like:
  (revision-id, tree-subset, arbitrary blob of bytes)
The primitive monotone provides, of course, is:
  (revision-id, arbitrary blob of bytes)
Obviously the latter is strictly more general, at least in principle.

> OF course, one can add to the statement, that actually the statement
> only concerns a subset of the tree (ie a file or set of files) and not
> the whole tree. While technical possible, I consider it a hack, because
> monotone itself or related tools will never understand and support this
> statements. Hence, no point in using certs for this purpose (for me).

But your objection isn't to what's technically possible, but to what
will seem natural and supported, which is fair enough.  Monotone
_could_, for instance, just store and throw around signed blobs of
bytes, and leave even the "revision-id" part up to convention; but we
don't.  The question is where best to draw this line between
generality and utility.

Monotone actually understands very very little about certs.  Branch
certs are magical -- many parts of the code take action depending on
their presence/absence -- but for other certs:
  -- some get special selector characters, instead of having to rely
     on the generic c:certname=certvalue selector (tag, author, date)
  -- some get special display in 'log' output (author, date, changelog,
     tag)
  -- 'update' looks at 'testresult' certs
That's... everything I can think of.  Even branch certs aren't that
magical, they're mostly used to mask out various subsets of the
revision graph (e.g., in netsync) and choose sensible defaults (e.g.,
update, propagate, and merge targets; branch-based checkout).

So, I guess where I'm going is... what sort of "understand[ing] and
support" do you expect from monotone and related tools?  They barely
understand existing certs, except for particular ones that they have
some special use for (e.g., a log browser might have special code to
interpret 'date' certs and convert to local timezone, but that doesn't
affect any new certs, only 'date' certs.)

I don't think we'd be against adding such a concept, if it was shown
to be useful.  A major reason for certs existing in the first place
is to support things like code review workflows, in fact...  I
strongly encourage everyone to experiment with ways to do this, and
would be really curious to hear about your experiences.  For now,
though, I think it still makes sense for monotone to simply provide
the most general, flexible primitive, and then if experience shows
that it would be useful to fold some extra support back into the core
monotone, well, then we'll actually know _what_ support would be most
useful :-).

If that makes sense?

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho