RE: How well does CVS handle other types of data?

[Greg A. Woods]

[ On Friday, July 13, 2001 at 09:25:58 (-0500), Thornley, David wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Because, so far, nobody's shown me how to make my problems, such as they
> are, easier to manage than if I just use CVS.

Well, that might just be because you can't do that.  I.e. you can't
still have your cake and have eaten it too.

> Let's go through a possible scenario.  We cut off a release_12 branch.
> Joe works on a feature we've promised for release 13, and checks in his
> work, including changes to a binary file.  Sara works on a bug left in
> release 12, fixes it, including changes to that binary file, and checks
> it in.  Sara then has to merge it.  She merges, and gets a conflict on
> the binary file.  This is a pain, since she has to take care of that
> somehow, but I fail to see that it is an avoidable pain.

Well, what is that binary file?  How you handle it best, inside or
outside of CVS, depends on what it is.

Further, what are the intent of each of Joe and Sara's changes?  Should
both those intents be carried into the merge result?  Neither?  Either?

> If we have the binaries in carefully named directories, then Joe changes
> the binary in the head branch directory, Sara changes it in the release 12
> directory, and promptly overwrites Joe's change when she merges to head.
> If we use RCS files in carefully chosen directories, then we've got Joe's
> version and Sara's version, and we've still got to merge them somehow.

Why do you have to merge them?  What is in this precious file?  How do
you express the intent of each change?  Should the person merging the
code make the decision on what to keep in the binary non-mergable file?
Why can't you re-create a third variant that honours both intents (if
indeed that's what's desired)?

> The only way we can avoid merging such files, it seems to me, is not
> to have branches.

That's one way.  You could also simply define strict procedures for
manually re-creating changes in plain RCS files, for example.  I.e. if
you have an artist make on variant of an icon have a red background, and
decide you'd like it to be that way for a bunch of other variants (eg.
on other branches), then you'd not "merge" the change -- you'd have the
artist reproduce the intent of the change in all those other variants
because even a sophisticated image merging program will not likely be
able to make an artistically pleasing result automatically.

>  For reasons I won't go into deeply, this is not an
> option.  We sell very complex software and have to maintain different
> releases (yes, that's a pain, but right now that's the way it is).
> Managing changes to several different releases without VCS branching
> would require manual branching and merging.

If you keep your binary files outside of CVS (or, heaven forbid, even in
a separate module in CVS), you might just be able to avoid branching and
merging them.  It all depends on what's in them.

In the now infamous example of the hammer and screwdriver icons the
decision on which to use might not even reside with the configuration
manager.  In this sense there is no change history, per se, of the icon
files.  There's just an ever increasing set of such icons and which ones
are pulled into the final product is an artistic decision, not one based
on the revision history.  Keeping the icon file revisions far and away
from the source code revisions is the best way to ensure that unrelated
forces cause change to the icons which is not artistically suitable.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>