Richard S. Hall wrote:
Daniel Fagerstrom wrote:
In the future we might want to have separate release cycles for
different bundles, but currently it would complicate things without
any gain. We can restructure with trunk, tags and branches at the
bundle level if/when we actually need it.
Well, I expect the core framework release to be somewhat independent
of other bundles. The core framework will generally not ship with any
bundles other than what is required for its shell.
So, in short, if the directory structure dictates release cycles, then
it should accomodate this fact.
SVN doesn't exactly dictate any particular directory structure, but
using something like:
felix/
proj1/
trunk/
tags/
branches/
proj2/
trunk/
tags/
branches/
...
for each sub project with separate release cycle would be closest to the
SVN communities recomendations
(http://svnbook.red-bean.com/en/1.1/ch05s04.html#svn-ch-5-sect-6.1). The
(sub) project roots could of course be part of a hierarchy as Niclas
proposed. A repository structure like the one above becomes a little bit
unconvenient for developers as one need to checkout "proj1/trunk",
"proj2/trunk" etc instead of just "felix/trunk".
That can in turn be solved by using SVN externals
(http://svnbook.red-bean.com/en/1.1/ch07s04.html), which are somewhat
like symbolic links. With extrenals we could have a "felix/trunk" that
just contain external links to "proj1/trunk" etc. Then a developer just
need to check out "felix/trunk" to get a complete development
environment. We used this in Cocoon and it worked well except from that
it become much slower to update a project with lots of external links
than updating the same amount of code in just one big project. As a
result we decreased the number of external links and decided to solve
the problem with independent release cycles when needed. We have maybe
50 sub projects (blocks) in Cocoon, so the problem would be much smaller
in Felix especially if we avoid putting files at the top level so that
one in most cases only need to update or commit one sub project.
But I don't think we need to handle the problem with separate release
cycles yet. As long as we keep the sub project as separate, it will be
easy to reorganize when we need it.
/Daniel
