Location of subprojects in SVN

[Reinhard Poetz]

Joerg Heinicke wrote:

On 15.04.2008 12:23, [EMAIL PROTECTED] wrote:


Author: reinhard
Date: Tue Apr 15 09:23:00 2008
New Revision: 648313

URL: http://svn.apache.org/viewvc?rev=648313view=rev
Log:
mv subprojects into trunk

Added:
cocoon/trunk/subprojects/
  - copied from r648312, cocoon/subprojects/
Removed:
cocoon/subprojects/


Is there a reason for that? When I want to check out Cocoon trunk I 
don't want to have all the subprojects of it, do I?


My first idea was to move our subprojects (SSF, Spring configurator, JNet, Block 
Deployment) to cocoon/subprojects but this would have mae it more difficult to 
run a complete build of trunk because you would have to make sure that you build 
the subprojects first.


Of course this could be solved by having releases of all subprojects and use 
them instead of the SNAPSHOTs, but we haven't reached that point yet for JNet 
and Block Deployer.


Considering this I propose that we leave the subprojects _for now_ in 
cocoon/trunk/subprojects and move them out as soon as all 4 subprojects have 
been released.


WDYT?

P.S. I'm going to move the SSF and Spring configurator stuff later this day. If 
there is somebody having pending commits, 'svn switch --relocate' should help.


--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: Location of subprojects in SVN

[Joerg Heinicke]

On 16.04.2008 08:35, Reinhard Poetz wrote:


URL: http://svn.apache.org/viewvc?rev=648313view=rev
Log:
mv subprojects into trunk



Is there a reason for that? When I want to check out Cocoon trunk I 
don't want to have all the subprojects of it, do I?


My first idea was to move our subprojects (SSF, Spring configurator, 
JNet, Block Deployment) to cocoon/subprojects but this would have mae it 
more difficult to run a complete build of trunk because you would have 
to make sure that you build the subprojects first.


Of course this could be solved by having releases of all subprojects and 
use them instead of the SNAPSHOTs, but we haven't reached that point yet 
for JNet and Block Deployer.


Considering this I propose that we leave the subprojects _for now_ in 
cocoon/trunk/subprojects and move them out as soon as all 4 subprojects 
have been released.


WDYT?


As a temporary solution that's fine.

Joerg