Re: cvs update to branch with -f option

[Bob Bowen]

Larry Jones wrote:
> 
> address@hidden writes:
> >
> > Each branch has a few developers working on a handful of files.  A
> > developer working in a branch performs a checkout for the branch with the
> > -f option, giving him an entire repository to work from consisting of the
> > branched files, and the remainder of the repository from the main trunk.
> > This developer then commits his changes to the branch for the other
> > developers working in his branch.  The other developers working in that
> > branch then perform an update to the branch with the -f option, again
> > giving them the files committed by other developers in that branch and the
> > remainder of the repository from the main trunk.
> >
> > This method works well for us, except when the -f option is used, I would
> > like to get the non-matching files from a tag, rather than from the main
> > trunk (eg HEAD).
> 
> Branch the entire repository and stop using -f.  Branches are cheap,
> particularly if you never commit anything on them.  And by branching
> everything, you can branch wherever you want to get particular revisions
> of certain files (e.g., at a particular tag).

The disadavantage to branching the entire repository is that you have to do
unnecessary maintenance to keep up with changes in areas that you aren't
changing. So, when you say "branches are cheap", I'm not sure that you're
accounting for the entire cost. The overhead in the CVS implementation is fairly
cheap (once you have spent the time to create them), but the total cost in
making sure you have the right content can be considerable.

(This is one useful thing about ClearCase's config specs - it enables you to
select the appropriate version of various parts of your tree.)

The way we've worked around this (which is admittedly a kludge, but it gets what
we need) is to define modules which correspond to the populations of the various
branches and then do a series of checkouts to construct the versions you need.
If you have cases where the modules overlap in some way, always check out the
"default" versions first to set up the complete tree and then successive
checkins will replace the more specific files that you want. It doesn't work if
you do it in the opposite order because CVS doesn't have a good way to express
the complement of a module.

Running update in this hybrid workspace generally does what you want because for
each file it updates the version according to the sticky tags for that file.
Adding new files and directories in this situation does take special care to
make sure things are going to the right branch. Realize also, that when you want
to update your "base" versions, you have to completely reconstruct the workarea
- the checkout ordering is extremely important.

Like I said, this isn't pretty, but it is possible. The complexity involved has
more to do with the limitations of module naming than having the ability to
default to a tag. I've raised the issue of -f behavior before in this forum and
the general consensus is that it doesn't work in any useful fashion.

Hope this helps,

=Bob=

Bob Bowen  address@hidden  Process Engineering  (952)876-4635