This chapter is intended to review various scenarios and describe in each case effective ways of using darcs. There is no one ``best practice'', and darcs is a sufficiently low-level tool that there are many high-level ways one can use it, which can be confusing to new users. The plan (and hope) is that various users will contribute here describing how they use darcs in different environments. However, this is not a wiki, and contributions will be edited and reviewed for consistency and wisdom.
This is how darcs itself is developed. There are many contributors to darcs, but every contribution is reviewed and manually applied by myself. For this sort of a situation, 'darcs send' is ideal, since the barrier for contributions is very low, which helps encourage contributors.
One could simply set the _darcs/prefs/email
value to the project
mailing list, but I also use darcs send to send my changes to the main
server, so instead the email address is set to
``Davids Darcs Repo <droundy@abridgegame.org>
''. My .procmailrc
file on the server has the following rule:
:0: * ^TODavids Darcs Repo |(umask 022; darcs apply --reply darcs-devel@abridgegame.org \ --repodir /path/to/repo --verify /path/to/allowed_keys)This causes darcs apply to be run on any emails sent to ``Davids Darcs Repo''. Apply actually applies them only if they are signed by an authorized key. Currently, the only authorized key is mine, but of course this could be extended easily enough.
The central darcs repository contains the following values in its
_darcs/prefs/defaults
:
apply test apply verbose apply happy-forwardingThe first line tells apply to always run the test suite. The test suite is in fact the main reason I use send rather than push, since it allows me to easily continue working (or put my computer to sleep) while the tests are being run on the main server. The second line is just there to improve the email response that I get when a patch has either been applied or failed the tests. The third line makes darcs not complain about unsigned patches, but just to forward them to
darcs-devel
.
On my development computer, I have in my .muttrc
the following
alias, which allows me to easily apply patches that I get via email
directly to my darcs working directory:
macro pager A "<pipe-entry>(umask 022; darcs apply --no-test -v --repodir ~/darcs)"
This section describes the development method used for the density
functional theory code DFT++, which is available at
http://dft.physics.cornell.edu/dft
.
We have a number of workstations which all mount the same /home
via NFS.
We created a special ``dft'' user, with the central repository living in that
user's home directory. The ssh public keys of authorized persons are added to
the ``dft'' user's .ssh/allowed_keys
, and we commit patches to this
repository using darcs push. As in Section ,
we have the central repository set to run the test suite before the push goes
through.
Note that no one ever runs as the dft user.
A subtlety that we ran into showed up in the running of the test suite.
Since our test suite includes the running of MPI programs, it must be run
in a directory that is mounted across our cluster. To achieve this, we set
the $DARCS_TMPDIR
environment variable to ~/tmp
.
Note that even though there are only four active developers at the moment, the distributed nature of darcs still plays a large role. Each developer works on a feature until it is stable, a process that often takes quite a few patches, and only once it is stable pushes to the central repo.
David Roundy 2004-12-14