[cvsnt] Re: Modules and Shared Libraries - tagging strategy?

Torsten Martinsen torsten at tiscali.dk
Fri Nov 12 22:12:40 GMT 2004


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.


Bo Berglund wrote:

>OK,
>can you then explain how using import can make it possible for the developers
>to update the common code and commit it to the original location???
>  
>
It cannot (and should not, IMHO).

>To do what you propse means the following operations (correct me if wrong):
>
>1. cvs export the common files you need for the new project into a folder
>   in the new project sandbox.
>
>2. cvs import these folders and specify the location to be a part of the
>   new project module (a submodule).
>  
>
Exactly.

>With these operations the common sources are effectively disconnected from the
>new module and what you have accomplished is to create a duplicate of the common
>code inside the new project.
>If someone else using the common code finds and corrects a bug and commits his
>changes it will not be reflected in your project, nor will it be committed to
>the original common folder. Thus noone else will benefit from the bugfix...
>
>I still think using import is not appliable in this circumstance.
>  
>
You are correct in that any changes in the imported code do not 
automatically propagate back to the original module. However, this 
should be considered an advantage (as Jurko Gospodnetic also points 
out), because this always creates a risk of breaking other code which 
depends on the shared code.

Propagating changes to the common library should only be done through a 
controlled process, IMHO (e.g. after being reviewed by the configuration 
control board or similar).

-Torsten



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