Jamie Webb wrote: > On Sun, Nov 19, 2006 at 07:12:46PM +0100, Thomas Hafner wrote: >> 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). > > You would probably be ok if settings.h did not appear in the trunk > repository at all, but I suspect you will be better off keeping a > single codebase and e.g. using the build system to configure it.
To elaborate the latter suggestion: I think the idea is to maintain two files settings-B.h and settings-A.h, then add make/build rules to copy (or symlink) either one of them to settings.h, depending on some build parameter. A disadvantage of this approach is that you loose the ability to move patches between version A and version B. It all depends on whether this happens often enough to justify teh overhead of maintaining two branches. If the versions have few things in common then it is unlikely that a change in one version can (or rather: should) be merged into the other one; in this case two separate files (and thus one main repo w/o branches) are probably easier to manage. OTOH, if large parts of settings.h are the same for both versions and the common parts are changed often, then two repos (branches) for the two versions make sense. However, another solution would be to factor out the common parts, maintain them in a separate file, and combine the common parts with the version specific parts during build. Ben _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
