On Wed, Nov 4, 2009 at 5:22 AM, <J.B.C.Engelen@...1578...> wrote:
I don't know what my opinion is. Having bug-likely stuff in a branch is nice of course.
However, a practical problem of large refactoring is that it touches the source in many different places. This makes it very likely that changes in trunk coincide with refactoring changes in the branch. A lot of time (and frustration) will be spent merging in changes from trunk. This is also true for non-refactoring but invasive new features, like LPE was.
Exactly. And a better SVN with easier branches won't change that. Let's not be carried away by the shiny new tools. Branches' freedom can easily turn sour. Whenever there's a chance to effect a change by a series of focused, well-planned changes in the trunk, each of which leaves it in a workable state, this should be preferred to branching.
I think more important than a branch is a teamed effort for big projects. From my own experience, refactoring alone is no fun; refactoring in a team (thanks Verbal and Diederik!) is much more fun. So I feel that before anyone should take up refactoring, he should find a team to do it with. This reduces the risk of 'vacation' or 'sick of it' problems.
Exactly. That's why we're doing Inkscape in the first place :) It is so much more than the sum of what each of us could do alone.