[cvsnt] Import best practice / import technical problems (CVSNT bug?)

Tobias Rodenbach tr.mailinglists at gmail.com
Thu Feb 14 10:36:28 GMT 2008

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.


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

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