Ooh... now I really get to do some Subversion evangelism :-)
On Tue, Nov 05, 2002 at 10:30:28AM +1100, Peter Donald wrote:
>...
> If there was mixed codebases (C/C++/java/perl/python) you would update a lot
> more stuff than is necessary. While it is still true when it is all java
> (several people complained that excalibur was too big to update), mixing all
> sorts of languages in there would be prohibitively expensive.
Yup. Could get a bit big.
> The other option of only updating the projects you know you will use requires
> that end users know all the dependencies and remember to update all of them
> everytime they need an update. This is painful for new users and a little
> error prone.
Right.
> * 5 out of 11 said they wanted mail separated based on language
> * 6 out of 11 said they wanted mail separated based on concept
I can understand this.
Okay... so here is my suggestion. Let's use Subversion's "externals"
concept. This is very similar to CVS modules in that it aggregates multiple
locations into a logical view. Unlike CVS, however, users can maintain these
views (rather than asking a CVS admin to edit CVSROOT/modules), and the
externals respond properly at "update" rather than just "checkout" time.
Envision a structure like this:
/ -- root of repository
/trunk -- the main trunk (a line of development)
/code -- flat set of components
/serf
/avalon-FOO
/avalon-BAR
/views -- different views of the repos using svn:externals
/c
/java
/python
/http-clients
/foo-topic
/tags -- just copies of path/rev pairs to simplify browsing
/serf
/0.0.1
/0.0.2
/avalon-FOO
/0.4
/0.4.2
/alpha
/branches
???
Each of those directories in the /views area has an svn:externals property
set on it. That property picks and chooses the components from /trunk/code.
We can set up new views at will. As a new Java component is added, somebody
adds it to the svn:external property on /trunk/views/java and commits that
property change. Next time people updated, the new property arrives, and the
new component is checked out.
The normal behavior is for somebody to check out one of the views.
Alternatively, somebody could just check out /trunk/code and get all of the
components.
[ note that people shouldn't try to check out some of those higher-level
dirs such as / or /trunk, as they would get *huge* duplication on the
client side ]
Of course, we could reorganize the structure over time.
> * All of the non-Apache people wanted per-component announce lists.
Too bad for them :-) (IMO) Apache Commons is the release and announcement
vehicle, so all the info comes directly from A-C rather than the components.
The ASF needs to be the releaser-of-code to ensure that it retains full
liability for future problems; for the ASF to release the code, that means
the formal release is an activity sanctioned/monitored by the PMC.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
