On Apr 19, 2010, at 03:53, ja...@smars.pl wrote: > Ok, it seems to be ok but has some disadvantages: > > when I commit changes on either trunk, this change is made only on > /share/module_1234 (the revision number of project1 or project2 will not > increase). > Because of the above there is no information in show log of > project1/project2.
I guess you have each project in its own repository? Ok. The strategy is that each project, and each module, has its own release schedule. So if you make a change to module_1234, then you release (i.e. tag) a new version of module_1234. And then, as a second step, for each project that uses module_1234, you update that project to use that new version of that module. This implies that the external defined in each project does not refer to the module's trunk but to a tag of that module. So at minimum you'd update the external definition to point to the new version of the module. Possibly, you'd also need to make other changes to the project, if you've changed the module's interface or added new functionality to the module that you now want to use in the project. > The trunk history of the latest changes is very handy. > Also any commit to the trunk should trigger the auto build, and in these > case it won't. (unless the /share/ is also watched by the auto build tool, > which is actually not a problem) Also solved by the above since now there is a commit in the project's repository whenever you switch to a new version of the module.
