Jim Hurley wrote:
If folks think that is needed or would be helpful to figure out other svn management issues - that's cool. I'm not the right person to lead that discussion, so (if it's important) someone should grab the ball and get it started...
I don't believe it is necessary to draft guidelines with regard to branching at this stage, having said that ... I agree the trunk is the right place for committing code for which committers believe there is consensus for receiving that fix/feature. Experimental stuff can be done in an experimental branch if coordination is required between various people or when committers want to show that code to the world, otherwise their IMO ones own sandbox is just fine. Proper IDEs have local version control as well, or you can use one of the many available version control systems. Subversion is rather weak with regard to integrating changes between various branches so it is wise to branch only when things have really stabilized, or we should use a different version control system that keeps track of the integration history. Not that integrating changes from one branch to another will ever become easy when time elapses ;-) When a different policy becomes effective for a certain codebase it is wise to branch, such as with the stabilizing phase when the feature set for a new release has been (almost) completed. That brings me to my most important point, what is withholding us from branching the current trunk into a release X and we start with the next phase where people can work on what they want to work on. -- Mark
