On Tue, Apr 22, 2008 at 10:04:16AM +0200, J.B.C.Engelen@...1578... wrote:
I will be doing under-the-hood refactoring, and I am thinking about whether or not to work in my own svn branch. Pros: I can break builds with partial commits and/or make bad bad bugs. Cons: I won't discover bad bugs.
Well, no doubt some bugs will be evident from mere "smoke testing". "Discover[y of] bad bugs" is of course also the other half of "breaking things for users": more specifically, using trunk doesn't get the advantage of discovering bad bugs except by breaking things for users.
I'd like to work in trunk, because of the bugs issue and because it will force me to immediately handle new code by others.
Re immediately handling code newly added to trunk, I was hoping that svn would make it easy to "re-root" / re-seat / re-target a branch, i.e. "move/adapt the branch" to a different split point. I believe that BitKeeper had this as a goal, and consequently I hoped that git and possibly even svn would do so. At the least I suppose it should be possible to do so semi-manually, i.e. to create a version that's the merge of splitpt:trunk-head and splitpt:branch-head, and create a new branch from this.
If svn doesn't make it convenient to keep a branch up-to-date with HEAD then perhaps should use git-svn, bzr-svn or the like?
Moreover, I will be forced to make changes that build and function and won't be drawn into making a half-way solution that will not work at the end of GSOC.
There is that psychological "advantage" if you trust your current judgement over your future judgement about the trade-offs involved in the extra work of making things less likely to have bugs or more generally palettable for trunk in exchange for making it more likely that something will be left in trunk at the end of GSoC. I'll note that future judgements will be more informed about the specifics of the situation, though I haven't thought about the psychological effects that might bias future decisions towards the wrong decision.
I expect that some of the intermediate steps in the transformation involved in JohanE's project in particular will be net regressions in terms of performance and messages to stderr (warnings of possible bugs).
The matter of what goes into trunk and when may be influenced on what improvements are available from a project when it is only part-way finished.
pjrm.