[Monotone-devel] Re: Rosterify and certificate keys

[Wim Oudshoorn]

Richard Levitte - VMS Whacker <address@hidden> writes:

> In message <address@hidden> on Mon, 10 Apr 2006 22:36:44 +0100, Joel Crisp 
> <address@hidden> said:
>
> Actually, he's talking both about automatically generated changelogs
> (that's what I understands that he means with "propage Changelog
> entries") and changelogs that he write himself that include a revision
> hash, and it's for the latter that I'm asking why he feels the need
> to, so I can understand that particular situation better.

It seems that nobody uses certificates a lot :-)
Well, a reason to put a revision hash in a certificates is for example:

Revision tree:

                  /---... .... -------- B  
                 A 
                 \----... ... .. -----... C - D - ....


changelog on B:
        Merged in changes between C and D


Here you for example explicitly name revisions C and D.

Or another example:
 

           A - B - C - D - E 

and you want to back out the changes between B and D.  
You can do:

          A - B - C - D - E
                       \ 
                        F

With the content of F equal to B and add the certificate to F:

changelog:

   backout changes between B and D.


This will not work with disapprove.


> jcrisp> In which case, your comment about the relevancy is accurate,
> jcrisp> but inapplicable.
>
> I disagree.  For the automatic changelogs, it's absolutely
> applicable.

I should resist to nitpick, but the temptation is too much :-)

I agree the information is there in the revision graph.  So I would
say, either don't write the revisions in the changelog, or make
sure they are correct.  Now after upgrading to 0.26 all
the propagate changelog entries are 'misleading'.  


For me the ideal situation would be that during the conversion all
the certificates that contain a string of 40 hex digits that equal
an existing hash should be replaced with the new, post upgrading hash.

Also, if the private key is know, it should try to preserve the private key,
otherwise fallback to a default private key when resigning the certificates.

I understand that this is much more work, but it would have been nice.

> jcrisp> On the other had, montone clearly states it is not a 1.0
> jcrisp> product, so anyone using it must be aware that the only
> jcrisp> certain thing is change.... ;-)
>
> Yup, that's quite true.

Ah, yes I agree, but I can dream and hope ;-)

Oh and I hope no one takes this the wrong way, I am very happy with monotone.

Wim Oudshoorn.