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? In effect, that after the import a user checking out from the branch might get files from the newer vendor version? 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! > 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? > If that's the case then you would be better off to forget "cvs > import" and simply always do full merges on a "normal" branch > created for the vendor (where you manually check in and manually tag > new vendor releases instead of importing them). 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). This means that you have to sort out which files were added and which files were deleted manually, or write a script for this. This far I understand. Then what you do about "local" changes. I don't quite get your scheme. /npat -- A commune is where people join together to share their lack of wealth. -- Richard M. Stallman _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
