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 firstname.lastname@example.org.
Rick Martin wrote: > Do you still maintain a vendor branch for their code? Currently I don't, but I did. (Maybe not "their" code, but "these other guys'" code :) > So if I understand correctly, you're checking out their code on the > vendor branch and manually deleting all the files except the CVS > sub-dirs. Depends who "they" is and how you get the code. Sometimes, you get it delivered a zip file through download, for example. In any case, you get updated source code packages every now and then. > Then installing the update to the sandbox and then committing the > changes, add new files and removing deleted ones? At first, I place the vendor code where I want it. Then I add it all to my repository, just as I would with anything else and commit it. Then (or before that) I think of a branching scheme. Having the vendor's code on a branch has advantages. But maybe you keep the vendor's code on the trunk and have your mods on a branch... Depends on how that fits in with the rest of your branching philosophy. Anyway, when I get an update from the vendor (zip file, checkout from their repository, CD, whatever), it goes where the vendor code should be -- be that the trunk, or a branch. The important thing here is that you clean out completely the sandbox where you keep your checked-out copy of the vendor code before you copy in the new set of files -- except of course the CVS subdirectories. These need to remain intact when you clean out the sandbox. After this, WinCvs will show you clearly which files are missing now (they need to be cvs-removed), which files are new (they need to be cvs-added), and which are modified. This step is also a quickie review of the modifications the vendor code underwent. You can even run a quick diff wherever something looks like it might be of interest for you. The time for this step (which basically is what you would not have to do if you used cvs import) is not wasted, usually. Then you commit the new vendor code (and tag it :). > I think I like it. I've been using import but their are a lot steps > involved and the potential for screwup is always large. Yes. I never got proficient in cvs import. I tried it once, it seemed unpredictable and not offer any advantage over this other procedure, which is comprised of a few steps I know well. And import seems less flexible, if you need a different branching scheme (like the OP). Gerhard