Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tobias Rodenbach wrote: > we have a module in CVS which was imported some time ago using > something like "cvs import -n <module_name>", i.e. without using a > vendor branch. After doing some modifications on our side we will now > receive an update from the supplier and therefore realized that having > a vendor branch would not be such a bad thing after all. Basically > there are two known ways to handle updates from the supplier > A) As mentioned in the CVSNT manual/Cederquist in section "Tracking > 3rd party sources", i.e. having a main trunk and a vendor branch, > importing vendor releases and (if necessary) merge from the vendor > branch. > B) As mentioned in "Software Configuration Management patterns"by S. > Berczuk, i.e. having a vendor branch (or tracking vendor sources on > main) and starting a new branch for local modifications based on each > vendor release and merging local modifications from branch to branch. > > We face problems with both ways. Our recent update contains structural > changes, i.e. deletions/additions of files/directories. Without these, > I guess everything would work smooth, at least for option B. Maybe something heretic... I don't use import (I don't even know how it works exactly :) I just put the vendor code on a branch (the "vendor branch") and, when an update exists, commit the new vendor code on that branch. Then merge the vendor branch into the vendor code on the development branch (HEAD or whatever it is). It is possible to tag the "clean" code on the vendor branch right after the commit, so it is not a problem to retrieve earlier clean releases at all. This procedure avoids all the special handling and uncertainties around import, and allows me to handle 3rd party code just as if it were "normal" code. Gerhard