[Tilesathome] 'stable' t at h version

[Carsten Möller]

spaetz schrieb:
> On Wed, Aug 27, 2008 at 01:06:35PM +0200, Knut Arne Bj?rndal wrote:
> 
>> If I've understood you correctly you want to setup a stable branch
>> where no commits go in before they have been tested by several
>> people. This kind of setup is more pain than it's worth because most
>> changes are small, simple and everyone is fairly sure it's going to
>> work.
>>
>> What we have recently had is a very big cleanup and reorganization of
>> code going on in trunk, what I'd rather see is for these kind of
>> changes to be done in a separate branch.
>>
>> There is a small but important difference between these setups, in
>> that only changes that we think might cause trouble are tested in this
>> way.
>>
>> If you want a super-stable branch with loads of testing then go right
>> ahead, it's not hard to get svn access, but don't expect every
>> developer to use loads of time and energy getting the code he's
>> written into some stable branch.
> 
> I haven't worked it out yet. For now, I will freeze the "stable" as it is and do development in _unstable
> Once in a while (about weekly?) I plan copying it over if it proves to be stable. I was thinking that regular development would happen in _unstable, yes.
> 
> I have little experience in branching with multiple developers, so I appreciate feedback and recommendations.
> 
> spaetz
> 
The normal structure would look like this:

.../tilesAtHome/trunk
.../tilesAtHome/branches
.../tilesAtHome/branches\maintenance (copy of current release maybe locked)
.../tilesAtHome/tags/release01
.../tilesAtHome/tags/release02

Development should be done in the trunk.
If it's stable, just svn-copy it to e.g. \tags\release01
It's just a pointer, not a physical copy, so don't worry.
Maybe this should be anchored in the config file so
one can decide whether he or she wants to render
safely or test an experimantal version.

If we want to differentiate between Windows, Mac and Linux
we could also have a branches/windows/mainenance and so on.
But maybe this goes too far.

Once again. Merging is not necessary.

Regards

Carsten