Carsten Möller <[EMAIL PROTECTED]> 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 _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
