river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: [PROPOSAL] Source drop and bug database
Date Thu, 04 Jan 2007 19:30:28 GMT
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

Mime
View raw message