[Buildbot-commits] buildbot/docs buildbot.texinfo,1.42,1.43
Brian Warner
warner at users.sourceforge.net
Tue Apr 11 06:13:01 UTC 2006
Update of /cvsroot/buildbot/buildbot/docs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18934/docs
Modified Files:
buildbot.texinfo
Log Message:
Revision: arch at buildbot.sf.net--2004/buildbot--dev--0--patch-490
Creator: Brian Warner <warner at lothar.com>
add Mercurial support
* buildbot/process/step.py (Mercurial): add Mercurial support
* buildbot/slave/commands.py (Mercurial): same
* buildbot/scripts/tryclient.py (MercurialExtractor): same
* buildbot/test/test_vc.py (Mercurial): same, checkout over HTTP is
not yet tested, but 'try' support *is* covered
* docs/buildbot.texinfo (Mercurial): document it
* buildbot/process/step.py (LoggedRemoteCommand.remoteUpdate): add
some debugging messages (turned off)
* buildbot/test/test_vc.py: improve debug messages
Index: buildbot.texinfo
===================================================================
RCS file: /cvsroot/buildbot/buildbot/docs/buildbot.texinfo,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -d -r1.42 -r1.43
--- buildbot.texinfo 7 Apr 2006 04:31:37 -0000 1.42
+++ buildbot.texinfo 11 Apr 2006 06:12:59 -0000 1.43
@@ -147,6 +147,7 @@
* CVS::
* SVN::
* Darcs::
+* Mercurial::
* Arch::
* Bazaar::
* P4Sync::
@@ -1043,9 +1044,9 @@
tag used in CVS)@footnote{many VC systems provide more complexity than
this: in particular the local views that P4 and ClearCase can assemble
out of various source directories are more complex than we're prepared
-to take advantage of here}. The SHA1 revision ID used by Monotone is
-also a kind of revision stamp, in that it specifies a unique copy of
-the source tree, as does a Darcs ``context'' file.
+to take advantage of here}. The SHA1 revision ID used by Monotone and
+Mercurial is also a kind of revision stamp, in that it specifies a
+unique copy of the source tree, as does a Darcs ``context'' file.
When we aren't intending to make any changes to the sources we check out
(at least not any that need to be committed back upstream), there are two
@@ -1206,6 +1207,13 @@
revision number, but the patch-reordering flexibility of Darcs makes
it impossible to provide a shorter useful specification).
+ at uref{http://selenic.com/mercurial, Mercurial} is like Darcs, in that
+each branch is stored in a separate repository. The @code{repourl},
+ at code{baseURL}, and @code{defaultBranch} arguments are all handled the
+same way as with Darcs. The ``revision'', however, is the hash
+identifier returned by @command{hg identify}.
+
+
@node Attributes of Changes, , How Different VC Systems Specify Sources, Version Control Systems
@subsection Attributes of Changes
@@ -1257,6 +1265,8 @@
@code{revision} is an int, a transation number (r%d)
@item Darcs
@code{revision} is a large string, the output of @code{darcs changes --context}
+ at item Mercurial
+ at code{revision} is a short string (a hash ID), the output of @code{hg identify}
@item Arch/Bazaar
@code{revision} is the full revision ID (ending in --patch-%d)
@item P4
@@ -1276,7 +1286,7 @@
combination of some base URL, the branch name, and the filename within
the branch. (In a sense, the branch name and the filename inhabit the
same namespace). Darcs branches are subdirectories of a base URL just
-like SVN.
+like SVN. Mercurial branches are the same as Darcs.
@table @samp
@item CVS
@@ -1285,6 +1295,8 @@
branch='branches/trunk', files=['src/foo.c']
@item Darcs
branch='branches/trunk', files=['src/foo.c']
+ at item Mercurial
+branch='branches/trunk', files=['src/foo.c']
@item Arch/Bazaar
branch='buildbot--usebranches--0', files=['buildbot/master.py']
@end table
@@ -2631,6 +2643,7 @@
* CVS::
* SVN::
* Darcs::
+* Mercurial::
* Arch::
* Bazaar::
* P4Sync::
@@ -2805,7 +2818,7 @@
will concatenate ``svn://svn.example.org/MyProject/'' with
``features/newthing'' to get the svnurl for checkout.
- at node Darcs, Arch, SVN, Source Checkout
+ at node Darcs, Mercurial, SVN, Source Checkout
@subsubsection Darcs
@cindex Darcs Checkout
@@ -2847,8 +2860,38 @@
will be passed to the @code{darcs get} command.
@end table
+ at node Mercurial, Arch, Darcs, Source Checkout
+ at subsubsection Mercurial
- at node Arch, Bazaar, Darcs, Source Checkout
+ at cindex Mercurial Checkout
+
+The @code{Mercurial} build step performs a
+ at uref{http://selenic.com/mercurial, Mercurial} (aka ``hg'') checkout
+or update.
+
+Branches are handled just like @xref{Darcs}.
+
+The Mercurial step takes the following arguments:
+
+ at table @code
+ at item repourl
+(required unless @code{baseURL} is provided): the URL at which the
+Mercurial source repository is available.
+
+ at item baseURL
+(required unless @code{repourl} is provided): the base repository URL,
+to which a branch name will be appended. It should probably end in a
+slash.
+
+ at item defaultBranch
+(allowed if and only if @code{baseURL} is provided): this specifies
+the name of the branch to use when a Build does not provide one of its
+own. This will be appended to @code{baseURL} to create the string that
+will be passed to the @code{hg clone} command.
+ at end table
+
+
+ at node Arch, Bazaar, Mercurial, Source Checkout
@subsubsection Arch
@cindex Arch Checkout
@@ -4128,6 +4171,10 @@
This can also be provided as @code{try_vc} in
@file{.buildbot/options}.
+The following names are recognized: @code{cvs} @code{svn} @code{baz}
+ at code{tla} @code{hg} @code{darcs}
+
+
@heading finding the top of the tree
Some VC systems (notably CVS and SVN) track each directory
@@ -4151,12 +4198,14 @@
for each tree you use, so it may be more convenient to use the
@code{try_topfile} approach instead.
+Other VC systems which work on full projects instead of individual
+directories (tla, baz, darcs, monotone, mercurial) do not require
+ at command{try} to know the top directory, so the @option{--try-topfile}
+and @option{--try-topdir} arguments will be ignored.
+ at c is this true? I think I currently require topdirs all the time.
+
If the @command{try} command cannot find the top directory, it will
-abort with an error message. Other VC systems which work on full
-projects instead of individual directories (tla, baz, darcs, monotone)
-do not require @command{try} to know the top directory, so the
- at option{--try-topfile} and @option{--try-topdir} arguments will be
-ignored.
+abort with an error message.
@heading determining the branch name
@@ -4176,8 +4225,13 @@
@table @code
@item CVS
-Wow, good question. We have to assume that you've done an @code{cvs
-update} on the whole tree... [TODO]
+
+ at command{try} pretends that the tree is up to date. It converts the
+current time into a @code{-D} time specification, uses it as the base
+revision, and computes the diff between the upstream tree as of that
+point in time versus the current contents. This works, more or less,
+but requires that the local clock be in reasonably good sync with the
+repository.
@item SVN
@command{try} does a @code{svn status -u} to find the latest
@@ -4204,7 +4258,7 @@
first line of @code{tla logs --reverse} to figure out the base
revision. Then it does @code{tla changes --diffs} to obtain the patch.
- at item darcs
+ at item Darcs
@code{darcs changes --context} emits a text file that contains a list
of all patches back to and including the last tag was made. This text
file (plus the location of a repository that contains all these
@@ -4216,8 +4270,15 @@
what your tree's base revision is, and then does a @code{darcs diff
-u} to compute the patch relative to that revision.
+ at item Mercurial
+ at code{hg identify} emits a short revision ID (basically a truncated
+SHA1 hash of the current revision's contents), which is used as the
+base revision. @code{hg diff} then provides the patch relative to that
+revision. For @command{try} to work, your working directory must only
+have patches that are available from the same remotely-available
+repository that the build process' @code{step.Mercurial} will use.
+
@c TODO: monotone, git
- at c TODO: new VC systems: mercurial (hg)
@end table
@heading waiting for results
More information about the Commits
mailing list