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 :)
