If I understand you correctly:
You have some source files that are common to all your work.
You have some source files that have slight differences in the different
versions.
Then, do the following:
1. Have a file 'machine.h'. Include this.
#define MACHINE machine_name
2. Have a file 'machineSwitch.h'. Include this.
#define machine1 1
#define machine2 2
#define machine3 3
#if MACHINE==machine1
#define flags-for-machine1
#endif
#if MACHINE==machine2
#define flags-for-machine2
#endif
#if MACHINE==machine3
#define flags-for-machine3
#endif
3. Create a branch for each machine, from the base revision.
In the base, 'machine.h' contains a blank line.
In the branches, it contains one line defining the machine name.
4. Always supply a '-j machine-branch' (the branch name you used in #3) on
updates.
We have just recently had to do this ourselves.
5. For files that are NOT cpp based (no preprocessor support like this), then
again, try to keep the 'base vs machine' switch down to one line.
For example, .eomodeld (Apple EOModeler directories) contain an
'index.eomodeld' file that specifies what machine has the database to connect
to. The difference between these versions is a one line change, per file.
6. When you add a new machine, you then create a new branch, and commit only
that one (or few) files, with just the new machine name on it.
7. When a new file needs to get this behavior, you create the same set of
machine branches for that file.
(Note: Having HAD to do this makes me realize that my previous "How can you
determine the parent branch?" questions were very, 'short-sighted' -- it
really can vary on a per-file basis, and not have a meaning per-module.)
===
ALTERNATIVE:
After reading your description again, I have this idea/suggestion.
It looks like you have only some files that differ, but they need to be
completely different. (Resource files, perhaps? Do resource files permit
#ifdef's?) Other files are not different.
You want to have some files on a branch, and some files not on a branch.
When you check out files, you want to get the branch versions of files that
have it, and non-branch versions of files that do not have it.
'-f' will force a head match on checkout/update if the branch tag isn't
found.
So, the first thought is to make some files have the various machine branch
tags, and others not.
This almost does what you want. 'cvs update -f -r machine' does work.
But it tags every file that was checked out, even if that file didn't have
the branch. ** Is this a bug? **
And, you cannot use '-f' on commit (it has a different meaning there). So,
you cannot commit any changes you make. (** this may be a feature wanted **)
Michael
[EMAIL PROTECTED] wrote:
>
> I need some help to decide whether to use a branch or whether some other method
> is more appropriate.
>
> I'm a relative newcomer to CVS. I am using it to control a project that consists
> of two Windows DLLs (I'm working with Microsoft Developer Studio and WinCVS,
> with the repository on a UNIX box). Call them main.dll and site.dll.
>
> main.dll is core code common to all installations of the software. site.dll is
> installation-specific.
>
> I want to know what is the best way to manage this project in CVS. My initial
> thought was to create a branch for each different installation. So for the A
> site, I would choose the A branch, edit the code for site.dll and rebuild the
> project.
>
> I hit an immediate snag when CVS didn't appear to allow me to specify which
> files were to be in the branch. Further reading made me think that perhaps this
> is not what branches are intended for. A branch appears to be a way of creating
> a copy of an entire project isolated from the main trunk, which at a later date
> might merge back with the main trunk. I want to separate off a couple of files
> from the project and make several different versions of these files, the
> versions being related as brothers rather than as father, son, grandson, and
> then choose which version I have checked out along with the common code so I can
> build the appropriate version of site.dll.
>
> Everything is in one module at present. Would I be better off if I had put the
> DLLs in separate modules? If so, what would I do with the source files that are
> common to both DLLs? If I need to split this into two modules, can I do this
> easily without losing the version histories?
>
> I would be very grateful for all suggestions that I receive.
>
> Ian Goldby
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept
> for the presence of computer viruses.
>
> Power Technology Centre, Ratcliffe-on-Soar,
> Nottingham, NG11 0EE, UK
> Tel: +44 (0)115 936 2000
> http://www.powertech.co.uk
> **********************************************************************
