Re: [Monotone-devel] Re: Rosterify and certificate keys

[Wim Oudshoorn]

Timothy  Brownawell <address@hidden> writes:

> On Tue, 2006-04-11 at 10:14 +0200, Wim Oudshoorn wrote:
>> 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:
>
> Hmm, I'd probably try to use something human-readable for these cases...

Of course you want something human readable, but in addition to a human
readable description you use the revisions ids to pinpoint exactly 
the revisions you talk about.

>> Revision tree:
>> 
>>                   /---... .... -------- B  
>>                  A 
>>                  \----... ... .. -----... C - D - ....
>> 
>> 
>> changelog on B:
>>         Merged in changes between C and D
>
>    Cherrypick from <branch that C and D are on>
>    <whatever the changelog for D says>

No, I don't want to quote the changelog of 'D'.  
Because
        a - it duplicates information.   
        b - it does not really  help  you in finding
            out which revisions exactly you are talking about.

Of course in real life the changelog would be worded more like:

   'merged bug fix BUG-ID from XXX branch 
    from rev id: ....
    to rev id: ....'


>> 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.
>
>    backout command syntax changes
>    <changelog entries from C and D, prefixed with "don't" or "undo">

More or less the same reasoning applies here.  I want to see when
looking at F exactly which commits are reverted.  Of course in the changelog
you want some description of which changes are reverted, but I also would like
exact information.

Wim Oudshoorn.