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