Hi Graig,
Craig L Russell wrote:
On Jan 4, 2007, at 10:23 AM, Mark Brouwer wrote:
This also raises a question, how are we going to manage all this. From
SVN I get the impression the website is a separate branch in the
repository, but do we have to check-in all 'subprojects' into one trunk.
The way I use the term, a branch is a copy of a trunk that has the same
content structure and much of the same contents, with some changes here
and there. So if you want to work on a disruptive feature, you can
branch the trunk, iterate until it all works, leaving the trunk
buildable, and after the branch is complete, merge it to the trunk. You
can then delete the branch if you have no further use for it.
You can also branch for a release. Development continues on the trunk
and changes needed to stabilize the release are checked into the branch.
Also, artifacts are changed in the branch to reflect the release number
of the release. After release, both branch and trunk continue to exist.
This sounds very familiar to the way one should work with Perforce so I
think I'm aligned. Way of working is the same, tooling is different.
In the end I hope the River project becomes a TLP with various
subprojects such as core, lus implementation, javaspaces implementation,
etc.. Each with their own release schedule. Dumping everything in one
trunk doesn't seem very handy to me, but as I already mentioned I'm an
SVN infant so maybe this works out well. Anyone?
I don't think it matters much whether you have a structure like:
I think it really matters, for the reasons you gave yourself :-)
1)
trunk/
core/
javaspaces/
lus
or
2)
core/
trunk/
javaspaces/
trunk/
lus/
trunk/
If you release a number of related things together, that argues for a
common trunk, as 1).
This is the current state for the JTSK so that argues for 1), however
ServiceUI is a separate project.
But in time I hope the JTSK is split up in individual pieces that will
evolve each on their own pace, I really don't have a clue however at
what time during the project this should happen.
If the projects are truly separate in release schedules, that argues for
separate high level projects, as 2). It's easy to release one project at
a time but harder to coordinate releasing multiple projects simultaneously.
This is what I'm aiming for.
--
Mark
