Re: Merging, keyword expansion, binary files

[Greg A. Woods]

[ On Wednesday, December 19, 2001 at 09:53:39 (+1000), Nicholas Catanchin 
wrote: ]
> Subject: Merging, keyword expansion, binary files
>
> I'm trying to perfect my tracking of third-party sources and I think I
> have stumbled into my last problem :)
> The third-party software that I am using is modified/enhanced on a daily
> basis and I really want to stay up to date with it. The process I am
> going through is:
> 
> 1. Checkout latest version of third-party source
> 2. Import into vendor branch with new release tag (using date of import
> as release tag)
> 3. Merge changes together
> 
> Problem starts here. Merge works fine (thanks to Larry) except that
> every file that has been modified has a conflict due to the $Id$ keyword
> being present. I read up on this and found that I can specify the '-kk'
> option on merge to set the keyword to not expand (or something like
> that). That worked fine - except that all the binary files present get
> screwed up. But then when I go to commit the merged sources the binary
> files that have just been corrupted are not committed for some reason
> (is this a feature?). SO - problem solved? Or not?

Binary files just do not work well in CVS, especially when you need to
do merging, and you almost always need to do merging when you start
making local modifications to a vendor branched module (i.e. binary
files work even less well in vendor branched modules than in any other
way of using CVS).

However all may not be lost.  I've got several GIF and JPEG files in my
third-party source repository and I've never had any problem with them,
not in nearly eight years of using CVS for managing gigabytes of third
party code.

What you need to do is to _always_ check out your vendor branched
modules with the (sticky) '-ko' option.  In other word you basically
have to tell CVS to NEVER touch any keywords or their values in any file
in your vendor branched module.  You really don't want to be messing
with another project's keyword values anyway.

You want to make sure you use '-ko' when doing merges too as sometimes
new files will need it to be set (unfortunately '-ko' isn't sticky per
directory instead of per file).

I always do my merges in an existing directory too, never simultaneous
with a checkout.  I don't know if that makes any difference or not, but
it doesn't seem to hurt!  ;-)

You should also keep in mind that vendor branched modules work by
merging vendor changes to the local (trunk) branch for any locally
changed files, but by copying for any unchanged files.

Also remember that unfortunately a file that has been removed by the
vendor and then the name is used again for a new (version of the) file,
CVS will forever more treat that file as locally changed even though the
only change was to mark the file dead for it's initial removal in your
repository.  This has unpleasant consequenses if you also have local
changes in the post-death version of the file, though they're mostly
cosmetic and only slightly increase the effort you must go to when
merging new vendor releases.

-- 
                                                                Greg A. Woods

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