Re: Vendor branches and head revisions

[Greg A. Woods]

[ On Friday, May 17, 2002 at 14:33:34 (+0300), Jouni Heikniemi wrote: ]
> Subject: Vendor branches and head revisions
>
> 
> I've tried browsing the list archive, but couldn't find a comprehensive
> answer on this neither in the archives nor the documents. So I'll just 
> ask:
> 
> We have the normal scenario with a software vendor providing updated
> sources every now and then and lots of hacking going on between the vendor
> releases. Now the problem with cvs import is that it marks locally
> unmodified files as the trunk's head revision, possibly causing trunk to
> be in uncompilable state until the branch is merged completely. This is
> not acceptable, as merges can take days or even weeks.

Yes, that's exactly right.  The "cvs import" and the following merge are
intended to be somewhat atomic operations.  Since normal branches don't
work well with imported sources either you're kind of restricted to big
freezes when it comes time to incorporate a new vendor release....

Of course you could modify every file so that it lives on the trunk.
Then normal branches work better (though obviously without conflict
detection during the import), and even the trunk remains stable during
an import and merge.  However that'll likely lengthen your already
lengthy merge process.

> I'll list out what I have figured from the various sources. I'd greatly
> appreciate corrections and proposals for better approaches.
> 
> - The best way around the mentioned problem is to use normal branches
> - Import doesn't work properly on non-vendor branches
> - Therefore the updates should be done by checking out a fresh sandbox
>   from the "vendor" branch (really a normal one), copying the 
>   modified files over the old stuff and then committing.
> - After this, merges could be done like with any other branches.
> 
> Is this actually doable, and what problems am I to expect?

It's actually quite easy.  If you're familiar with merging between
branches then you shouldn't expect any new problems.

> At least I know
> I'll have to cvs add and rm files by hand before the import-commit;

Do you mean "after the copy and before the commit" ? :-)

> is
> there a good way of doing this automatically?

Identifying the files to be added with CVS is easy.  They're all the '?'
files listed with "cvs -nq update".

Removed files can be a little harder to spot.

In times I've done this before I've just done a simple "diff" of the
sorted file listings from the relevant releases of the vendor's source
archive.

        tar -tvf version-1.tar | sort > version-1.list
        tar -tvf version-2.tar | sort > version-2.list
        diff version-1.list version-2.list

The lines prefixed with '<' are the files to be removed:

        cvs rm -f $(diff version-1.list version-2.list | awk '$1 ~ /</ {print 
$2}')

(that's syntactically correct but not tested in a live working
directory, however I think it should work, and it should be easy enough
to undo its effects if it fails :-)

You could write some trivial scripts to help with adding new files (and
several can be found in the list archives), but I find using PCL-CVS
it's quite easy to zip along and clean up even thousands of new files in
less than an hour.

-- 
                                                                Greg A. Woods

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