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

[Gerhard Fiedler]

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