> -----Original Message----- > From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 23, 2005 6:58 AM > To: oscar-dev@incubator.apache.org > Subject: Re: Felix SVN trunk root > > > SVN doesn't exactly dictate any particular directory > structure, but using something like: > felix/ > proj1/ > trunk/ > tags/ > branches/ > proj2/ > trunk/ > tags/ > branches/ > ... >
I'm pretty sure this will be something that will arise fairly quickly for the framework development. We might want go ahead and think about this kind of organization. > 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. > I like that approach, which I believe also falls in line with Jeff's recommendation of one project per bundle. > 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. > Why wait? -tbennett
