[cvsnt] Multiple vendor branches

Gerhard Fiedler lists at connectionbrazil.com
Wed Mar 14 17:50:43 GMT 2007

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.

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).


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook