Seeking advice for repository design

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 [COLOR=#FF0000][FONT=courier new]main.c[/FONT][/COLOR], ProjectA contains a copy of [COLOR=#FF0000][FONT=courier new]main.c[/FONT][/COLOR] plus its own [COLOR=#FF0000][FONT=courier new]a.c[/FONT][/COLOR] 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. [FONT=verdana][SIZE=14px][B]Issue 1: Repository: Single Project or Multi-Projects[/B][/SIZE][/FONT] 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 [COLOR=#0000FF][FONT=courier new]git init[/FONT][/COLOR] or [COLOR=#0000FF][FONT=courier new]hg init[/FONT][/COLOR] 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. [I]Pro:[/I] [LIST=1] [*]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. [/LIST] [I]Con:[/I] [LIST=1] [*]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. [/LIST] [FONT=verdana][SIZE=14px][B]Issue 2: Using a Multi-Project Repository[/B][/SIZE][/FONT] Another way is to go with a multi-projects repository similar to this: [LIST] [*]Framework [LIST] [*]trunk [LIST] [*]main.c [/LIST] [*]branches [*]tags [/LIST] [*]ProjectA [LIST] [*]trunk [LIST] [*]main.c [COLOR=#008000]// Copy of Framework/trunk/main.c[/COLOR] [*]a.c [/LIST] [*]branches [*]tags [/LIST] [*]ProjectB [LIST] [*]trunk [LIST] [*]main.c [COLOR=#008000]// Copy of Framework/trunk/main.c[/COLOR] [*]b.c [/LIST] [*]branches [*]tags [/LIST] [*]Project ... [LIST] [*]trunk [*]branches [*]tags [/LIST] [*]ProjectZ [LIST] [*]trunk [LIST] [*]main.c [COLOR=#008000]// Copy of Framework/trunk/main.c[/COLOR] [*]z.c [/LIST] [*]branches [*]tags [/LIST] [/LIST] Is there a way to make all projects sync their copy of [COLOR=#0000FF][FONT=courier new]main.c[/FONT][/COLOR] with the latest version from Framework project through Subversion? Or it is better to do it using a proper makefile or build script? [FONT=verdana][SIZE=14px][B]Issue 3: Use Branch for Project[/B][/SIZE][/FONT] 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. [LIST] [*]Framework [LIST] [*]trunk [LIST] [*]main.c [/LIST] [*]branches [LIST] [*]ProjectA [LIST] [*]a.c [/LIST] [*]ProjectB [LIST] [*]b.c [/LIST] [*]Project... [LIST] [*]....c [/LIST] [*]ProjectZ [LIST] [*]z.c [/LIST] [/LIST] [*]tags [/LIST] [/LIST] [SIZE=14px][FONT=verdana][B]Issue 4: Dependent projects, linked projects, sub-projects[/B][/FONT][/SIZE] 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 3 years ago

Subversion repositories are very stable. You keep them on a server and do not let normal people directly touch the bits. As such corruption is very, very rare. And Subversion repositories can grow to very, very large sizes (in terms of disk space). So scalability in that dimension is not a problem either. I would recommend a single MultiProject Subversion repository. NOTE WELL: Git and Mercurial are DVCS's and when you clone the repositories you clone the entire repository. That motivates developers to keep the repositories as small as possible. And that's why they tend to use a repository per project. Subversion is quite the opposite. When you checkout you only get the data for the revision requested. That keeps the data transfer small. Note: if you're developing on a Operating System that is "symbolic link friendly" then I would use symlinks in the project directories to point back to the "main.c" file so that it is automatically kept up to date. Note: you should not use branches for projects. Keep branches for branching. You'll need that for fixing things at a later time, or for doing investigations that might lead nowhere. If you're locked into a single IDE then you can use its features to maximum effect. The downside is if you need to port to a new IDE that does not have those features. Then you need to do the development to enable whatever that feature accomplished in some other way. What you need is someone who has worked in multiple IDE's that you are considering and based on their experience help guide you in terms of what features to use and what features NOT to use. That's not me.

I also still use SVN exclusively for every project I can control. What I like best is that I can keep my SVN repositories on a server I control and my team can remotely use the svn client software on that server to access the repositories we use for projects. Because we use Secure Shell sessions we can remote control the svn client under our logged in user accounts. This also keeps authentication of SVN repository users at the server level under Linux. So I can have users running SVN client side software on any platform and still access the repositories. I'm not a proponent of cloud-based repositories requiring special client side software on every workstation to access it. So most of us use TortoiseSVN which support remote SSH+SVN\\ style connections. Nice clean, orderly, and secure while still being convenient for all the authorized users.