[Chandler-dev] How we develop post Preview : SVN topology

[Grant Baillie]

There's an s3 here:

- Stable trunk (i.e. 0.7.x work) + per-feature (and/or per-developer)  
branches. This is essentially how twisted does things IIRC.

Personally, I don't have a particularly strong opinion about this  
choice. For example, no-one is singing the praises of s2, but I'd be  
fine with it. (Using SVK, it's not a big deal to merge properly  
between branches. My pattern is to make local branches often anyway).

--Grant

On 5 Sep, 2007, at 13:31, Philippe Bossut wrote:

> Possible strategies:
> 1. 2 main branches: one for "open" dev work going toward the next  
> major release and one for "restricted" commits to fix the official  
> release
> s1.a: Evergreen trunk: use the trunk for 0.7.x (restricted commit)  
> and open a dev branch. When the dev branch is stable, merge it to  
> the trunk (or call it the trunk) and repeat.
> s1.b: Open dev trunk: use the trunk for open dev toward the next  
> major release, open a branch for 0.7.x work. Note: wxWidgets for  
> instance is using such a strategy.
> s2. Multiple dev branches: maintain the trunk evergreen, devs  
> develop on their own branch and merge onto the trunk once their  
> feature/change pass tests and scrutiny by the community. Note: used  
> on really big FLOSS projects (Linux) and by commercial projects  
> (considered as best practice under Perforce for instance).