[ On Monday, July 24, 2000 at 11:18:37 (-0700), Stephen L Arnold wrote: ]
> Subject: questions on tracking 3rd party sources
>
> I assume this pre-supposes that the new version (wdiff-0.05) has the
> same directory structure, and the same set of (modified) source files
> as the previous version. What happens if the organization of the
> source tree was changed? How much can CVS do on it's own, or do I
> basically have to analyze all the changes beforehand and do a whole
> slew of "cvs add" "cvs rm" etc? (I was hoping CVS would help with
> this part).
No, not necessarily. CVS manages files, and only files. When a file
moves it is "removed" from its original location and "added" in its new
location. History is preserved, but only through indirection.
When you do the merge to pull the vendor changes into your local
release, like this:
cvs co -j WDIFF-0_04 -j WDIFF-0_05 wdiff
or if you have an existing, working directory:
cvs update -j WDIFF-0_04 -j WDIFF-0_05 .
As part of the merge CVS will mark those files that are no longer in the
vendor release as "removed", and if you'd worked on WDIFF-0.03 and there
had been a file in that release but which was removed in 0.04, then
added again in 0.05 CVS would mark that file as "added".
You would then commit these changes, including the removals and
additions, in order to bring your local set of files into sync with with
the latest vendor release.
Note that despite what the manual says, and despite what the hint given
at the end of the import says, you have to do the merge as above, after
every import, and you have to be sure to use the tags for the '-j'
options too.
> A couple sections farther in the manual is one called Multiple Vendor
> Branches, which uses the -b (branch tag) to distinguish between two
> different branches of the same code:
>
> $ cvs import dir RED RED_1-0
> $ cvs import -b 1.1.3 dir BLUE BLUE_1-5
>
> Would this be a better approach for me? What are the implications if
> I do it this way?
In my experience multiple vendor branches just do not work.
Even worse I would say that their mere concept is flawed. In theory if
you were trying to create a "super-release" where you imported all
changes from all vendor branches there might be some benefit. However
I've yet to see the conflict detection work 100% correctly when you have
more than one vendor branch (and conceptually I'm not sure it can), plus
of course
Note that you don't have to use the vendor branch at all. You can do
your "imports" on normal branches with only a minor amount of trouble.
In this case there is no such concept as "conflict detection on import"
and you have to do the merges from the manually created branchs to your
local branch (maybe the trunk?) manually, mostly as above, anyway.
In the end too I often find it easier to just start a brand new
vendor-branch module when too much has changed in the vendor release.
In most cases I only have a very few changes to re-apply to the new
release and that's one heck of a lot easier to do manually (or with the
assistance of diff & patch).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
