[Tilesathome] 'stable' t at h version

[Matthias Julius]

Carsten Möller <cmindividual at gmx.de> writes:

> 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.

Currently the client only does 'svn up' for its automatic updates.
This wouldn't be so simple with each new release being copied into a
new directory.  It would then need to be told by the server how the
new release is called and do 'svn switch <new_release>'.

Another approach could be to have the server tell clients to which rev
to update to and clients then do 'svn up -r<new_rev>'.  This has the
disadvantage that it makes it impossible to apply a bug-fix to the
stable version.

Matthias