gitversion-controlmercurialkohana-3

source control structure for a kohana based project


i currently have several projects using kohana as a framework, and what i have at the moment is a directory structure like this

project
- application
- system
- modules

the "project" dir is under mercurial source control, and i basically copy and paste modules that i use. and commit them to each project.

however i am now finding i fix a bug in a module and there is no easy way to propogate that fix to all the other projects using that module.

what i am wanting to do is link the modules somehow so i can easily get updates when i need them. (i have been looking at subrepos for doing this)

now i read up this on the mercurial site "Use a thin shell repository to manage your subrepositories"

https://www.mercurial-scm.org/wiki/Subrepository

so i came up with this concept

applications
- application1 (hg repo)
- application2 (hg repo)

mymodules
- mymodule1 (hg repo)
- mymodule2 (hg repo)

project  (hg repo)
- application (sub repo pointing to applications/application1)
- modules (several git repos on github, custom modules which are in mymodules/module1 repos)
- system (git repo on github)

website
- project (links to project repo, including application, modules and system)
- assets (images, css, etc)

now i am thinking that is a lot of structure and i am going a bit over the top for what is essentially a simple problem.

Also I am not sure how i should i be doing work.

  1. in my the website repos and pushing back to project, which would get pushed back to the application, and modules etc

  2. or should i be working on the application repos and pushing up to the website level?

So is this the best way to structure things?

also is it necessary to have a local clone of all the github modules i use, to speed things up?

any help appreciated


Solution

  • The subrepos solution is a good one, as it allows to separate:

    How to make it works means how you organize your release management process.
    You should make modifications from your repos, and then propagate them to the deployment structures (through updates within projects, and then update of project within website).