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.
Hi, 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. A) is not very satisfying because - if no local change exists on a file, "import" will place it on the main trunk, leaving HEAD in an inconsistent state until I merge modifications from the vendor branch - reproducing "clean" vendor releases, in particular those previous to the latest one seems to be impossible. This is because the release tag I specify with the import command is put only to files that are both modified on local and on vendor side. Manual tagging would be an option but faces the same problem as described in B). - in our particular case we would have to do some magic to create the vendor branch on the already existing module B) Does not work with CVSNT because - When importing to main (with -n) files that exist on main but not in the imported release are not removed, i.e. when I check out HEAD, I will get the new release plus the files that were present in the old release. - It seems that this could be avoided by using import with -C, which will create "CVS" directories on the local copy that I am importing which should allow me to tag just the files that have been imported (but I would still prefer to remove the other files). However, this feature does not seem to work: When I use -C, CVS directories are created, but the status is incorrect. E.g. have a file <file> which already has revisions 1.1 and 1.2 in the repository. After the import, the repository contains the revisions 1.1, 1.2 and 1.3 with 1.3 having identical content as my local copy as expected. But "cvs status" states that the Working revision is 1.1 and it does so for all imported files. This behavior seems just wrong to me, unless for an initial import of course. Or is there any reason for this? Does anyone has any other best practices in mind how to efficiently track 3rdparty source code that is also locally modified and will frequently contain structural changes? CVS Server and Client versions are 2.5.03 (Servalan). Best regards Tobias