Hello,
I was thinking to a new idea of repository structure.
The core and libraries do not overlap, so no conflict here. For modules have three directories: - modules - store common integrated modules now (tm, db drivers) and modules that exist only in one project - modules-k - K modules that overlap in name with S modules or other particular K modules not moved to "modules" directory - modules-s - S modules that overlap in name with K modules or other particular S modules not moved to "modules" directory
As soon a new integration is done for overlappin modules, it will be moved to modules and removed for modules-k/modules-s
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
Opinions?
Cheers, Daniel
On 02/26/2009 09:53 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
if i make a commit on a k module, i just call the script again and get a new version of k compiled.
Yes, that would work (manually copying), but I find that more difficult than it should be (everybody will have to use some script and have at least 2 local repos, one for sip-router and one for the modules).
i don't see having two repos on the local disk as a problem. before copying, the script updates both automatically to latest level. i can write the script and post it on the list once the repos are in place.
i see it a much bigger problem if the same thing (sip-router) source is in two different places.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev