Changes between Version 20 and Version 21 of UsingPidginMonotone

Timestamp:

Apr 15, 2007, 2:40:36 PM (17 years ago)

Author:

elb

Comment:

--

UsingPidginMonotone

@@ +1 @@
+[[TOC]]
 = Using Montone for Pidgin =
 
@@ -52 +53 @@
 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.
 
-Creating a new branch is as easy as committing a revision with a new branch name, or adding a new branch certificate to an existing revision.  The former is accomplished at commit time by supplying the {{{-b}}} or {{{--branch}}} argument to {{{monotone commit}}}.  The latter is accomplished with the command {{{mtn approve -b <branch-name> <revision>}}} or {{{mtn cert <revision> branch <branch-name>}}}.  Branch names are not structured (that is to say, their structure is not ''enforced''), but good practices for branch naming suggest that related branches have similar names.  BCP seems to be Java-style inverted-domain naming.
+==== Creating a new branch ====
+
+Creating a new branch is as easy as committing a revision with a new branch name, or adding a new branch certificate to an existing revision.
+
+To create a new branch from a set of changes in your workspace (that is, commit a revision with a new branch name, supply the {{{-b}}} or {{{--branch}}} argument to {{{monotone commit}}}.  In other words:
+
+{{{
+mtn ci -b <new-branch-name>
+}}}
+
+Creating a new branch from an existing revision is accomplished with one of the commands:
+
+{{{
+mtn approve -b <new-branch-name> <revision>
+mtn cert <revision> branch <new-branch-name>
+}}}
+
+==== Branch naming ====
+
+Branch names are not structured (that is to say, their structure is not ''enforced''), but good practices for branch naming suggest that related branches have similar names.  BCP seems to be Java-style inverted-domain naming.  We are using this practice, with all Pidgin.im-related branches living under the im.pidgin namespace, with further hierarchy below this.  For example, the 2007 Summer of Code projects are all beneath im.pidgin.soc.2007.<projectname>.  Naming like this tells us something about the branches immediately upon executing {{{mtn ls branches}}}.
+
+==== Merging branches ====
 
 Merging two branches is accomplished with the command {{{mtn propagate <from-branch> <to-branch>}}}.  There are other ways to merge (''e.g.'', approve or cert a revision onto the destination branch, and then handle as a micro-branch below), but this is the most straightforward and will normally serve your purposes.