Reputation:
[note: I moved this from serverfault, as stackoverflow is probably more appropriate]
For a project we are working on we are developing a WordPress theme, some WordPress custom plugin, an iOS application and an Android application. We handle all source code via an internal Subversion server, where each project has its own repository.
My question is: what is the optimal lay-out for the SVN repository for this project? Can I fit it in 1 repository, or should I really create separate repositories for the theme, the plugins and the mobile apps?
Upvotes: 2
Views: 62
Reputation: 76276
The question is not whether separate repositories, but whether they should be managed as separate projects or not, which translates to whether they will be branched and merged together. In Subversion you can have multiple projects in one repository, so you can always have just one repository there.
The answer depends on how closely the modules will be tied together. If you expect any version of one component to work with, within reason, any other version of the other components, than they should be managed as separate projects (each with it's own trunk
and branches
, so you'd have theme/trunk
and theme/branches
and plugin/trunk
etc.). If you expect that modifications will commonly touch more than one component, they have to be managed as single project (one trunk
and branches
, so you will have trunk/theme
and trunk/plugin
etc.).
On a side-note, I'd suggest reconsidering the choice of subversion. The newer distributed systems (in order of popularity Git, Mercurial and Bazaar) offer more flexibility and superior branching and merging. The subversion implementation still shows rough edges after those years, in major part because the underlying model is not very good fit for branching.
Unlike subversion, distributed systems always have one project per repository, because branches are separate concept there, so you would have separate repositories (on one server anyway) if you decide to have separate projects.
Upvotes: 2