Re: Please help with merge!!!!!

[Wim Kerkhoff]

Larry Jones wrote:
> 
> Stephen Leake writes:
> >
> > Here's the process:
> >
> > 1) Unpack the vendor's version 1.0 distribution twice; one "clean"
> >    copy, one I will modify.
> >
> > 2) Make my modifications.
> >
> > 3) Run 'diff' to get a single diff file showing all my modifications.
> >
> > Now, when Vendor version 2.0 comes along:
> >
> > 1) Unpack Vendor version 2.0 twice.
> >
> > 2) Run 'patch' to apply my version 1.0 changes to version 2.0.
> >
> > 3) Make more changes.
> >
> > 4) Run 'diff' to make a version 2.0 patch file.
> >
> > This process is simpler than CVS when the vendor package is huge and
> > my local changes are small - a typical situation.
> 
> You must have a strange definition of "simpler".  If you're completely
> unfamiliar with CVS's vendor branch support (which it seems you are),
> then your process may well be more familiar or easier for you, but it
> most definitely isn't simpler.

Hmm... I've been doing something similiar to what Stephen is/has been
doing. That is, I store the vendor tarball (vendor-x.y.tar.gz), my patch
of changes, and a build-vendor.sh script that takes the tarball,
extracts, patches, configures, compiles, builds, and does whatever else
is necessary. This works, is automated, and both the patch are build
script are under revision control. Generally, our changes to vendor
source are quite small, and easily port to the next vendor version.
However, there are occasions where we make major changes.

I just read the section on vendor branches in the CVS book. It looks
like it could be a lot simpler; I prefer having inline conflicts rather
than a bunch of */*/*.rej files.

For smaller vendor sources, I can see that it will take less space in
the CVS repository when importing the sources, rather then the tarballs.
However, for something big (like the Linux kernel sources) I'd rather
import a 15MB .tar.bz2 file then the extracted sources (110MB).
Especially as we have very few modifications to it, and build-kernel.sh
takes care of applying various patches to it...

-- 

Regards,

Wim Kerkhoff, Software Engineer
Merilus, Inc.  -|- http://www.merilus.com
Email: address@hidden