changeset: 125:615321a1e60f
user: f.e.negroni_AT_gmail.com
date: Mon Aug 18 23:12:18 2008 +0100
files: dwm/customisation/myconfigh.md dwm/customisation/patch_queue.md
description:
More documentation about cutsomising dwm using MQ
diff -r 79706a6315e3 -r 615321a1e60f dwm/customisation/myconfigh.md
--- a/dwm/customisation/myconfigh.md Mon Aug 18 19:06:00 2008 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
_AT_@ -1,29 +0,0 @@
-#How to maintain your own config.h as a patch queue in Mercurial
-
-*blame [Filippo Erik Negroni](mailto:f dot e dot negroni at googlemail dot com>) about this document*
-
-This article will explain how to maintain your own `config.h` and `config.mk` files as a set of patches in a Mercurial Queue.
-
-##Background
-
-When customising dwm, it is assumed the user edits `config.h` and `config.mk`
-`config.h` is not generated from `config.def.h` when running `make`. The user must copy `config.def.h` in `config.h` before `make` can build its targets.
-This raises the interesting situation where our customised `config.h` does not match changes to `config.def.h` in future releases of dwm. We must therefore take care of diff'ing `config.h` and `config.def.h` manually so as to keep our customised `config.h` in sync with the project.
-
-When building dwm, the user is expected to edit `config.mk` to customise the install location and other parameters, such as C compiler flags.
-It is unfortunately suffering from the same risk of a customised `config.mk` not being in sync with the one in the main distribution. One has to remember to diff the original and customised `config.mk` to make sure the changes are in sync.
-
-##Automating our customisations
-
-Since *suckless.org* uses Mercurial as its source control system, it is nice to know that we can use Mercurial to manage our customisations. This makes it easy to create an incremental series of patchsets (queue) that we can also distribute to others.
-
-An example of such queue can be found at [fnegronidwm](
http://sharesource.org/project/fnegronidwm/wiki/): I created it as a Mercurial Queue repository so that I can manage the patches and keep them in sync with the main dwm distribution.
-
-The rest of this document will explain how I created my queue for dwm.
-It will hopefully help others do the same and also improve the quality of the patches by making sure that they are tagged and in sync with the main repository of dwm.
-
-##Tutorial
-
-### Clone dwm's main repository
-
-To be continued...
diff -r 79706a6315e3 -r 615321a1e60f dwm/customisation/patch_queue.md
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dwm/customisation/patch_queue.md Mon Aug 18 23:12:18 2008 +0100
_AT_@ -0,0 +1,68 @@
+#How to maintain your own config.h as a patch queue in Mercurial
+
+*blame [Filippo Erik Negroni](mailto:f dot e dot negroni at googlemail dot com>) about this document*
+
+This article will explain how to maintain your own `config.h` and `config.mk` files as a set of patches in a Mercurial Queue.
+
+##Background
+
+When customising dwm, it is assumed the user edits `config.h` and `config.mk`.
+
+`config.h` is not generated from `config.def.h` when running `make`. The user must copy `config.def.h` in `config.h` before `make` can build its targets.
+This raises the interesting situation where our customised `config.h` does not match changes to `config.def.h` in future releases of dwm. We must therefore take care of diff'ing `config.h` and `config.def.h` manually so as to keep our customised `config.h` in sync with the project.
+
+When building dwm, the user is expected to edit `config.mk` to customise the install location and other parameters, such as C compiler flags.
+It is unfortunately suffering from the same risk of a customised `config.mk` not being in sync with the one in the main distribution. One has to remember to diff the original and customised `config.mk` to make sure the changes are in sync.
+
+##Automating our customisations
+
+Since *suckless.org* uses Mercurial as its source control system, it is nice to know that we can use Mercurial to manage our customisations. This makes it easy to create an incremental series of patchsets (queue) that we can also distribute to others.
+
+An example of such queue can be found at [fnegronidwm](
http://sharesource.org/project/fnegronidwm/wiki/): I created it as a Mercurial Queue repository so that I can manage the patches and keep them in sync with the main dwm distribution.
+
+The rest of this document will explain how I created my queue for dwm.
+It will hopefully help others do the same and also improve the quality of the patches by making sure that they are tagged and in sync with the main repository of dwm.
+
+##Tutorial
+
+###Get the original dwm
+
+You have two options:
+- download the prepackaged source tarball (currently [dwm-5.1](
http://code.suckless.org/dl/dwm/dwm-5.1.tar.gz)
+- clone the mercurial repository at `
http://code.suckless.org/hg/dwm`
+
+###Enable the MQ extension
+
+In your global mercurial configuration (`~/.hgrc`), enable the MQ extension:
+
+ [extensions]
+ hgext.mq =
+
+Verify your extension is enabled:
+
+ $ hg help qinit
+
+###Prepare a base mercurial repository
+
+If you downloaded the prepackaged source tree, it is now a good time to initialise a mercurial repository:
+
+ $ cd dwm-5.1
+ $ hg init
+ $ hg add
+
+If you cloned the official repo, but prefer to work on less frequent updates, you can update your working copy to the latest stable tag:
+
+ $ cd dwm
+ $ hg up -r 5.1
+
+###Initialise the MQ repository
+
+From within your working copy, run the command:
+
+ $ hg qinit -c
+
+The `-c` option ensures that your patch series is tracked as a separate mercurial repository, should you wish to share it with others or experiment further.
+
+###Our first patch: change install location
+
+To be continued...
Received on Tue Aug 19 2008 - 19:01:52 CEST