Re: Merging from vendor-branch to branch

[Greg A. Woods]

[ On Wednesday, October 23, 2002 at 01:54:43 (+0300), Nick Patavalis wrote: ]
> Subject: Re: Merging from vendor-branch to branch
>
> On Tue, Oct 22, 2002 at 06:16:31PM -0400, Greg A. Woods wrote:
> > It's not really safe to use "normal" branches in a vendor-branched
> > module, at least not one in which you plan to do more "cvs import"s to
> > the vendor branch.
> > 
> 
> What do you mean!?! That if I create a branch (a normal branch), and
> latter do a "cvs import", then files on the *branch* can be affected?

No, but various operations which try to use the "normal" branch in some
way might be (adversely) affected.  I've seen and heard of problems, but
never bothered to really sort things out because it was immediately
obvious that the "normal" branch was ill-conceived and at odds with the
vendor-branched module.

> In effect, that after the import a user checking out from the branch
> might get files from the newer vendor version?

No, that's one thing that shouldn't happen.  Indeed that's part of the
problem though -- after an import and merge then the local branch will
still be stuck with base revisions of locally un-modified files at the
pre-import level and those files will explicitly have to have their new
vendor revisions merged to the branch.

> If this is so,
> then... well, this makes vendor-sources tracking (importing) almost
> useless!! I thought that I could always create a branch, ask the
> developer to work in it (instead of the trunk), and when when the
> trunk has stabilized ask them to switch back to the trunk. If this is
> not possible, then the whole idea of tracking 3rd party sources is
> unrealistic!

That actualy should work well enough just so long as _no_ imports are
done during the life of the "project" branch.

> > I've not tried to very carefully create a branch only on the trunk and
> > to merge "up" the head of the vendor branch to this branch, and then to
> > do an import and to do a merge on a branch.
> 
> huh?

        cvs rtag -b -r 1.1 local-branch foo-module
        cvs co -r local-branch foo-module
        cd foo-module
        cvs update -r 1.1 -r 1.1.1 .
        cvs commit
        cd ..
        tar -xvf foo-module-2.0
        cd foo-module-2.0
        cvs import foo-module FOO-MODULE FOO-MODULE-2_0
        # OOPS!  FUBAR

oh, never mind -- it wouldn't work.  The new checkouts or updates or
diffs or other work done in local working directories (i.e. from the
trunk) would still be "damaged" until the merge is complete......

sorry that was a bit of a blind alley....

> How could you do this? When you get new sources from the vendor you
> "hand-import" (i.e. manually commit) them to the "normal-vendor"
> branch (assuming it only contains sources form the previous vendor
> version, and no local changes).

Your local changes would be on the trunk and/or on some other "normal"
CVS branch(es).

For each local branch (or just the trunk) you'd do a normal merge of the
delta between the previous "vendor" release tag and the new "vendor"
release tag to a working directory checked out on that branch.

        cvs co -r the-vendor-branch -d vendor-foo-dir foo
        cd vendor-foo-dir
        pax -rvz -s s,^foo-2.0/,, -f /download-dir/foo-2.0.tar.gz
        cvs commit -m 'new foo-2.0' .
        cvs tag FOO-2_0
        cd ..
        cvs co -r the-local-branch -d local-foo-dir foo
        cd local-foo-dir
        cvs update -r FOO-1_0 -r FOO-2_0
        cvs commit -m 'merged foo-2.0 changes to the-local-branch' .
        cd ..
        cvs co -r another-local-branch -d local2-foo-dir foo
        cd local2-foo-dir
        cvs update -r FOO-1_0 -r FOO-2_0
        cvs commit -m 'merged foo-2.0 changes to another-local-branch' .

> This means that you have to sort out
> which files were added and which files were deleted manually, or write
> a script for this.

Yes, that's exactly what this means.  You would do this between the
"pax" and "cvs commit -m 'new foo-2.0' ." steps above, and execute the
appropriate "cvs add" and "cvs remove" commands just as if you were the
vendor working directly in the same repository.

> This far I understand. Then what you do about
> "local" changes. I don't quite get your scheme.

You will resolve conflicts with locally changed but vendor removed files
in exactly the same way as you would do in any normal branch-to-trunk
merge where files had been removed on the branch.

-- 
                                                                Greg A. Woods

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