[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [M10N] new repo layout
From:       Andreas Hochsteger <e9625392 () student ! tuwien ! ac ! at>
Date:       2005-11-03 20:37:22
Message-ID: 436A7502.7050307 () student ! tuwien ! ac ! at
[Download RAW message or body]


Daniel Fagerstrom wrote:
> The current structure with trunk/tags/branches under each block will 
> become rather unconvenient as soon as we start to relase and tag things.
> 
> Right now you can just check out svn:/cocoon/blocks without any 
> problems, but with a number of tags for each blocks you soon get quite a 
> lot to check out, then you either need to check out each 
> blocks/<name>/trunk separately or we have to provide a directory with 
> externals to each block trunk. But that was extremely slow when we tried 
> that a while ago.
> 
> Read the links in 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112790057318179&w=2 for 
> description of a better way to solve it.

I agree with your proposal.
When I had choose a layout during converting our CVS repository to 
Subversion I tried hard to find the layout which best fits our needs.

The most significant argument was, that if you choose the layout with 
trunk/tags/branches below every module you have to rename the directory 
every time you do a checkout (e.g. .../cocoon/trunk has to be checked 
out as cocoon). You don't have the convention anymore that checked-out 
directory names are identical with the ones in the repository.

If you do it the other way round (.../trunk/cocoon) your life is much 
easier (simply 'Checkout as Project' works again in Eclipse ;-).

Additionally you gain another benefit:
If you want to release multiple modules together you can put the tags 
for multiple modules under .../tags/<tagname>/<modulename>. This is not 
(easily) possible, if every module has it's own trunk/tags/branches 
directory.

Some (badly) written build scripts in other projects even depend on the 
correct directory name of their submodules...


Andreas
[prev in list] [next in list] [prev in thread] [next in thread]