I am a software developer currently developing a number of software. Each of them is a project for an Integrated Development Environment (IDE) like Visual Studio/Eclipse. Let's call them ProjectA, ProjectB ... ProjectZ. They will be largely variants based on a in-house developed template framework which is a project itself providing the skeleton structure. Let's call the project Framework. Each project contains additional unique files on top of the files from the template Framework. For example, if the Framework contains the file
main.c
, ProjectA contains a copy of
main.c
plus its own
a.c
It is hoped that whatever files that are updated in Framework can be automatically replaced in the other projects using it. So here's a few questions.
Issue 1: Repository: Single Project or Multi-Projects
Is it recommended to have 1 repository for 1 project or 1 repository for all projects? The single project repository structure however seems to be the default configuration and other version control systems like git and Mercurial. For each new project in a new directory folder, go a
git init
or
hg init
as a new local repository. Many IDEs also appear to assume this model. And TortoiseSVN (latest 1.9.5?) offers to create the trunk, branches and tags directories directly in the repository root after creating the repository itself. Pro:
Issue 2: Using a Multi-Project Repository
Another way is to go with a multi-projects repository similar to this:
main.c
with the latest version from Framework project through Subversion? Or it is better to do it using a proper makefile or build script?
Issue 3: Use Branch for Project
Since the projects are based on the main Framework project, another way is to have 1 Framework project in the trunk, and use a branch for each Project. This will then be a single project repository.
Issue 4: Dependent projects, linked projects, sub-projects
Yet another way of addressing Issue 3 is to use the IDE's support for dependent projects, linked projects or sub-projects or whatever the IDE calls them. Basically this states that a project build is dependent on a component or library or files from another project, and a project build automatically triggers a build of the sub-project in order to provide the resulting file output to be linked or included in the main project. In my case, the sub-project is the Framework that the others rely on. In this case, the IDE would provide the build automation to use the latest framework codes. All comments, suggestions and discussion are welcome.
main.c
, ProjectA contains a copy of
main.c
plus its own
a.c
It is hoped that whatever files that are updated in Framework can be automatically replaced in the other projects using it. So here's a few questions.
Issue 1: Repository: Single Project or Multi-Projects
Is it recommended to have 1 repository for 1 project or 1 repository for all projects? The single project repository structure however seems to be the default configuration and other version control systems like git and Mercurial. For each new project in a new directory folder, go a
git init
or
hg init
as a new local repository. Many IDEs also appear to assume this model. And TortoiseSVN (latest 1.9.5?) offers to create the trunk, branches and tags directories directly in the repository root after creating the repository itself. Pro:
- Any change and revision number will be localized to and therefore meaningful; the revision number won't increase when it is due to checked-in modified files in other projects in a multi-projects repository.
- Any corrupted repository will affect lesser files as it is scoped to 1 project only.
- The size of each repository would likely remain small and manageable.
- An unwanted project can be deleted permanently easily by deleting both working file folder and its repository directory. For multi-project repository, the repository can remove the files through SVN but not deleted totally from the file system and OS. A SVN delete of the project directory but the history of the deleted project remains.
- For each new software project based on the Framework, we have to repeat creating a new repository and configuring the repository and working files directory pairing.
- As each project repository is different, we have to manually update each one. In a multi-project repository, a single SVN update updates everything.
Issue 2: Using a Multi-Project Repository
Another way is to go with a multi-projects repository similar to this:
- Framework
- trunk
- main.c
- branches
- tags
- trunk
- ProjectA
- trunk
- main.c // Copy of Framework/trunk/main.c
- a.c
- branches
- tags
- trunk
- ProjectB
- trunk
- main.c // Copy of Framework/trunk/main.c
- b.c
- branches
- tags
- trunk
- Project ...
- trunk
- branches
- tags
- ProjectZ
- trunk
- main.c // Copy of Framework/trunk/main.c
- z.c
- branches
- tags
- trunk
main.c
with the latest version from Framework project through Subversion? Or it is better to do it using a proper makefile or build script?
Issue 3: Use Branch for Project
Since the projects are based on the main Framework project, another way is to have 1 Framework project in the trunk, and use a branch for each Project. This will then be a single project repository.
- Framework
- trunk
- main.c
- branches
- ProjectA
- a.c
- ProjectB
- b.c
- Project...
- ....c
- ProjectZ
- z.c
- ProjectA
- tags
- trunk
Issue 4: Dependent projects, linked projects, sub-projects
Yet another way of addressing Issue 3 is to use the IDE's support for dependent projects, linked projects or sub-projects or whatever the IDE calls them. Basically this states that a project build is dependent on a component or library or files from another project, and a project build automatically triggers a build of the sub-project in order to provide the resulting file output to be linked or included in the main project. In my case, the sub-project is the Framework that the others rely on. In this case, the IDE would provide the build automation to use the latest framework codes. All comments, suggestions and discussion are welcome.
Last updated