tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Re: Changing the subversion structure
Date Fri, 04 May 2012 15:05:48 GMT
On 12-05-03 04:39 PM, Mick Semb Wever wrote:
> I do like your proposal but am curious to why you say it must change.

1. Theory and project lifecycle

A tag encompasses the whole source tree, i.e. all 3 projects request, 
autotag and tiles would be present in each of the 3 tags request-1.0.0, 
autotag-1.0.0, and tiles-3.0.0.

Of course subversion can technically support whatever you want, but that 
is the convention behind the branches/tags/trunk structure, and people 
will expect us to adhere to it (starting with git-svn).

It's not a big issue when talking about tags, because tags are supposed 
to be immutable. The problem is more significant when talking about 
branches.

Suppose you fix a bug in TILES_3_0_X and another in REQUEST_1_0_X, you 
don't have a common source tree with both bugs resolved. Eventually the 
Tiles project in REQUEST_1_0_X or the Request project in TILES_3_0_X 
will become unusable, which will lead to one of these two solutions:
- Merging both branches with each other, which in the long term gets 
really messy.
- Have the developper ignore the projects which do not match the branch, 
which is error prone.

2. Tooling

We're using maven, which relies heavily on conventions. Usually you can 
use your own conventions with some effort, but that creates larger poms 
and more difficult to maintain.

Specifically, I'm not sure how mvn 
release:prepare/release:branch/release:perform would behave with all 
projects in a single svn tree. These commands are supposed to create the 
required tags/branches automatically, and automatically switch between 
them. I'm not sure how the current version of maven behaves in this 
situation, and I'm not sure how the future version will behave.

Even if it works or if it could be made to work, it is certainly not as 
well tested as the standard convention. And I see no point in taking 
chances there, I would really hate it if mvn release failed :)

Mime
View raw message