[darcs-users] several variants and developers at the same time

[Nimrod A. Abing]

On 19 Nov 2006 19:12:46 +0100, Thomas Hafner <thomas at hafner.nl.eu.org> wrote:
> Hello darcs users,
>
> how can variants handled with darcs? What's a resonable workflow, if
> there at least two developers are involved?
>
> Here's a very simple example with only two source files:
> - settings.h has different content for customers A and B.
> - foo.c never depends on the customer (no variants, but just the same
>   revision history for all customers).

I have a similar situation as you, the difference is that I am the
only developer on my projects. However, I have been doing this for
quite a while and it seems to work well. I maintain several projects
for several clients. All of them using the same basic codebase (the
language they are in is irrelevant in this context). Each client has a
different set of configuration settings all in one file. Some
configuration settings are common for all projects so they can be set
as reasonable defaults. However some projects require some settings to
be overridden.

The trick here is to do away with what I like to call "CVS mentality"
for a bit. Darcs is a decentralized revision control system so you
should treat it as such first and foremost. Keep in mind that each
"branch" is its own repository and you make in a "branch" can stay in
the branch. You have the *option* to keep a "central" repository where
changes that should be common to all projects should be pushed.

Here is my current workflow:

* Break up the configuration file into two files: 1 file to contain
defaults of common configuration settings (say common-settings.h). 1
file to contain per-project settings and overrides (say
local-settings.h).

Since you are using C, this is easily accomplished by using #ifdef,
#ifndef directives in the common-settings.h file. What you do is
#include the local-settings.h file *before* you define any defaults.

We break up the configuration file into two so that if one
configuration setting in common-settings.h is a dependency of a change
in another file (except local-settings.h), you can safely record them
both in one patch. Then you can push these changes to your central
repository and have your other developers synch up.

* Record changes to local-settings.h on its own. Do not record any
changes to this file with changes to other files. This way, you can
cherry-pick changes to this file and not push them to the central
repository. You can also use a prefix in the patch name (see below)
when recording changes to this file.

* If you have the need to make changes to the common code base, use a
prefix in patch names when recording those changes. The purpose of the
prefix is that you can use it in a ---matches option when doing a push
(e.g., ---matches="not name PROJ-A:") which will cause push to ignore
patches with that prefix.

I have written a small BASH script wrapper for darcs to take care of
handling ignored patches while that feature is still not available. I
can send it to you if you're interested.

As stated by Jamie Webb in this thread, you should take always care to
always record changes that belong locally in their own patches.

HTH.
-- 
_nimrod_a_abing_

[?] http://abing.gotdns.com