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

[Thomas Haas]

Nathaniel Smith wrote:
> 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)

In current monotone terminology a "tree-subset" would be a manifest?


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

Agree. And, I do not object or critic what monotone is doing, just
trying to understand what monotone actually does (features), and what
this means (semantic).

> 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 was thinking of much simpler support: you can say "monotone ls cert
REV-ID" and get what you expect. A graphical tool will (hopefully) allow
the user to view revision certificates, even if the tool does not
understand what the statement is about (and the tool will make an
assumption, that statements are of name-value nature).

However, I will not be able to tell "monotone ls cert
SOME-SORT-OF-FILE-ID" and no graphical tool will ever display file
related statements, because such a thing does not exist.


> 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?
> 

Sure. And I fully agree. For the time being I am fine to have learned,
that monotone does not support statements for files, only for revisions.

- tom


> -- Nathaniel
>