Changes between Version 21 and Version 22 of UsingPidginMonotone

Timestamp:

Apr 15, 2007, 7:36:30 PM (17 years ago)

Author:

rlaager

Comment:

s/im.pidgin.gaim/im.pidgin.pidgin/

UsingPidginMonotone

@@ -43 +43 @@
 Once you have created a key, you can generate a public key which can be shared with other developers (for the purpose of establishing trust, giving netsync permission, etc.) with the command {{{mtn pubkey $KEYID}}}.  The output of this command can be imported into a monotone database with {{{mtn read < $FILE}}}, and then synced to a remote server (even if it has not been used to sign any certificates) with {{{mtn push --key-to-push $KEYID}}}.  Note that if a key has been used to sign certificates which are communicated in a netsync transaction, it will be automatically synced along with the revisions; this means that if third-party developers use monotone (which we should encourage!) and we retrieve changes from them via mtn pull, their keys will be automatically installed in the pidgin.im repository at the next developer push of those revisions.
 
-== Branching {{{im.pidgin.gaim}}} ==
+== Branching {{{im.pidgin.pidgin}}} ==
 
 There are two kinds of branches in monotone, which I will call ''macro-'' and ''micro-''branches.  We will deal with each in turn.
@@ -49 +49 @@
 === macro-branches ===
 
-A ''macro-branch'' is a set of monotone revisions which have a particular certificate associated with them, identifying them as belonging to the same branch.  In our case, the "main" branch of development is {{{im.pidgin.gaim}}}.  All revisions in the monotone database which carry a cert of type {{{branch}}} with the value {{{im.pidgin.gaim}}} are on this branch.  Note that, technically, revisions on such a branch don't have to have any relation to one another -- however, it probably makes sense that they are all descended from some ultimate ancestor revision, and that they are logically related in some fashion.  In the case of {{{im.pidgin.gaim}}}, they form a (presently) linear history taken from the Gaim svn repository.
+A ''macro-branch'' is a set of monotone revisions which have a particular certificate associated with them, identifying them as belonging to the same branch.  In our case, the "main" branch of development is {{{im.pidgin.pidgin}}}.  All revisions in the monotone database which carry a cert of type {{{branch}}} with the value {{{im.pidgin.pidgin}}} are on this branch.  Note that, technically, revisions on such a branch don't have to have any relation to one another -- however, it probably makes sense that they are all descended from some ultimate ancestor revision, and that they are logically related in some fashion.  In the case of {{{im.pidgin.pidgin}}}, they form a (presently) linear history taken from the Gaim svn repository.
 
 Branch certificates are a little bit "magic", in that monotone knows about them and changes its behavior based on them.  For example, a {{{commit}}}ted revision will inherit the branch certificate of its parent.  An {{{update}}} on a workspace will update to the "newest" (DAG-wise; more on this later) revision bearing the same branch tag.  The set of revisions to synchronize via netsync is chosen by a branch specification pattern.
@@ -92 +92 @@
 }}}
 
-We call {{{a1b2c3d4}}} and {{{9876fedc}}} the ''heads'' of the branch {{{im.pidgin.gaim}}}, and the heads of a branch can be viewed with the command {{{mtn heads}}}.  I call this divergence (within the same logical branch {{{im.pidgin.gaim}}}) a ''micro-branch''.
+We call {{{a1b2c3d4}}} and {{{9876fedc}}} the ''heads'' of the branch {{{im.pidgin.pidgin}}}, and the heads of a branch can be viewed with the command {{{mtn heads}}}.  I call this divergence (within the same logical branch {{{im.pidgin.pidgin}}}) a ''micro-branch''.
 
 Such a micro-branch obviously cannot be resolved with {{{mtn propagate}}}, as both revisions are on the same logical branch.  To resolve such a branch, the command {{{mtn merge}}} is used.  Either {{{devA}}} or {{{devB}}} can merge these two revisions, say yielding a fourth revision {{{deadbeef}}}.  The resulting graph then looks like: