Using/Configuration
Configuring Darcs
There are several ways you can adjust darcs’ behavior to suit your
needs. The first is to edit files in the _darcs/prefs/
directory of a repository. Such configuration only applies when working
with that repository. To configure darcs on a per-user rather than
per-repository basis (but with essentially the same methods), you can
edit (or create) files in the ~/.darcs/ directory. Finally,
the behavior of some darcs commands can be modified by setting
appropriate environment
variables.
Microsoft Windows
The global darcs directory is %APPDATA%\darcs\. This
typically expands to
C:\Documents And Settings\user\Application Data\darcs\.
This folder contains the cache, as well as all the per-user settings
files: preferences, boring etc… These will became the new defaults that
can be overridden on per-repository basis. See also Windows.
prefs
The _darcs directory contains a prefs
directory. This directory exists simply to hold user configuration
settings specific to this repository. The contents of this directory are
intended to be modifiable by the user, although in some cases a mistake
in such a modification may cause darcs to behave strangely.
The configuration files can be split in three categories:
- remote prefs:
- motd
- post
- local prefs:
- author
- defaults
- sources
- boring
- binaries
- defaultrepo
- tmpdir
- internal metadata:
- prefs
defaults
Default values for darcs commands can be configured on a
per-repository basis by editing (and possibly creating) the
_darcs/prefs/defaults file. Each line of this file has the
following form:
COMMAND FLAG VALUE
where COMMAND is either the name of the command to which
the default applies, or ALL to indicate that the default
applies to all commands accepting that flag. The FLAG term
is the name of the long argument option without the “--”,
i.e. verbose rather than --verbose. Finally,
the VALUE option can be omitted if the flag is one such as
verbose that does not involve a value. If the value has
spaces in it, use single quotes, not double quotes, to surround it. Each
line only takes one flag. To set multiple defaults for the same command
(or for ALL commands), use multiple lines.
Note that the use of ALL easily can have unpredicted
consequences, especially if commands in newer versions of darcs accepts
flags that they did not in previous versions. A command like
obliterate could be devastating with the “wrong” flags (for
example –all). Only use safe flags with ALL.
~/.darcs/defaults |
provides defaults for this user account |
repo/_darcs/prefs/defaults |
provides defaults for one project, |
| overrules changes per user |
For example, if your system clock is bizarre, you could instruct
darcs to always ignore the file modification times by adding the
following line to your _darcs/prefs/defaults file. (Note
that this would have to be done for each repository!)
ALL ignore-times
If you never want to run a test when recording to a particular
repository (but still want to do so when running check on
that repository), and like to name all your patches “Stupid patch”, you
could use the following:
record no-test
record patch-name Stupid patch
If you would like a command to be run every time patches are recorded in a particular repository (for example if you have one central repository, that all developers contribute to), then you can set apply to always run a command when apply is successful. For example, if you need to make sure that the files in the repository have the correct access rights you might use the following. There are two things to note about using darcs this way:
Without the second line you will get errors, because the sub process that runs apply cannot prompt interactively.
Whatever script is run by the post apply command should not be added to the repository with
darcs add; doing so would allow people to modify that file and then run arbitrary scripts on your main repository, possibly damaging or violating security.apply posthook chmod -R a+r * apply run-posthook
Similarly, if you need a command to run automatically before darcs performs an action you can use a prehook. Using prehooks it could be possible to canonicalize line endings before recording patches.
There are some options which are meant specifically for use in
_darcs/prefs/defaults. One of them is
--disable. As the name suggests, this option will disable
every command that got it as argument. So, if you are afraid that you
could damage your repositories by inadvertent use of a command like
amend, add the following line to _darcs/prefs/defaults:
amend disable
Also, a global preferences file can be created with the name
.darcs/defaults in your home directory. Options present
there will be added to the repository-specific preferences. If they
conflict with repository-specific options, the repository-specific ones
will take precedence.
repos
The _darcs/prefs/repos file contains a list of
repositories you have pulled from or pushed to, and is used for
autocompletion of pull and push commands in bash. Feel free to delete
any lines from this list that might get in there, or to delete the file
as a whole.
author
The _darcs/prefs/author file contains the email address
(or name) to be used as the author when patches are recorded in this
repository,
e.g. David Roundy <droundy@abridgegame.org>. This
file overrides the contents of the environment variables
$DARCS_EMAIL and $EMAIL.
boring
The _darcs/prefs/boring file may contain a list of
regular expressions describing files, such as object files, that you do
not expect to add to your project. As an example, you could have:
\.hi$
\.o$
^\.[^/]
^_
~$
(^|/)CVS($|/)
A newly created repository has a longer boring file that includes many common source control, backup, temporary, and compiled files.
You may want to have the boring file under version control. To do
this you can use darcs setpref to set the value “boringfile” to the name
of your desired boring file
(e.g. darcs setpref boringfile .boring, where
.boring is the repository path of a file that has been
darcs added to your repository). The boringfile preference overrides
_darcs/prefs/boring, so be sure to copy that file to the
boringfile.
You can also set up a “boring” regexps file in your home directory,
named ~/.darcs/boring, which will be used with all of your
darcs repositories.
Any file not already managed by darcs and whose repository path
matches any of the boring regular expressions is considered boring. The
boring file is used to filter the files provided to darcs add, to allow
you to use a simple darcs add newdir newdir/* without
accidentally adding a bunch of object files. It is also used when the
--look-for-adds flag is given to whatsnew or record. Note
that once a file has been added to darcs, it is not considered boring,
even if it matches the boring file filter.
binaries
The _darcs/prefs/binaries file may contain a list of
regular expressions describing files that should be treated as binary
files rather than text files. Darcs automatically treats files
containing ^Z\ or '\0' within the first 4096
bytes as being binary files. You probably will want to have the binaries
file under version control. To do this you can use darcs setpref to set
the value “binariesfile” to the name of your desired binaries file
(e.g. darcs setpref binariesfile ./.binaries, where
.binaries is a file that has been darcs added to your
repository). As with the boring file, you can also set up a
~/.darcs/binaries file if you like.
The _darcs/prefs/email file is used to provide the
e-mail address for your repository that others will use when they
darcs send a patch back to you. The contents of the file
should simply be an e-mail address.
sources
The _darcs/prefs/sources file is used to indicate
alternative locations from which to download patches. This file contains
lines such as:
cache:/home/droundy/.cache/darcs
readonly:/home/otheruser/.cache/darcs
repo:http://darcs.net
This would indicate that darcs should first look in
/home/droundy/.cache/darcs for patches that might be
missing, and if the patch is not there, it should save a copy there for
future use. In that case, darcs will look in
/home/otheruser/.cache/darcs to see if that user might have
downloaded a copy, but will not try to save a copy there, of course.
Finally, it will look in http://darcs.net. Note that the
sources file can also exist in ~/.darcs/. Also
note that the sources mentioned in your sources file will
be tried before the repository you are pulling from. This can
be useful in avoiding downloading patches multiple times when you pull
from a remote repository to more than one local repository.
A global cache is enabled by default in your home directory. The cache allows darcs to avoid re-downloading patches (for example, when doing a second darcs clone of the same repository), and also allows darcs to use hard links to reduce disk usage.
Note that the cache directory should reside on the same filesystem as your repositories, so you may need to vary this. You can also use multiple cache directories on different filesystems, if you have several filesystems on which you use darcs.
motd
The _darcs/prefs/motd file may contain a “message of the
day” which will be displayed to users who clone or pull from the
repository without the --quiet option.
post
If _darcs/prefs/post exists in the target repository,
darcs send will upload to the URL contained in that file,
which may either be a mailto: URL, or an
http:// URL. In the latter case, the patch is posted to
that URL.
tmpdir
By default temporary directories are created in /tmp, or
if that doesn’t exist, in _darcs (within the current repo).
This can be overridden by specifying some other directory in the file
_darcs/prefs/tmpdir or the environment variable
$DARCS_TMPDIR or $TMPDIR.
defaultrepo
Contains the URL of the default remote repository used by commands
pull, push, send and
optimize relink. Darcs handles this file automatically or
when the flag --set-default is used.
prefs
Contains the preferences set by the command
darcs setprefs. Do not edit manually.
