Hi, We've so far avoided development branches because they might easily get out of sync with trunk and end up fragmenting development efforts. I think this is a reasonable strategy, but there are some cases where short-lived and tightly focused development branches might be a good idea.
For example in JCR-1579 I refactored the export functionality rather heavily and I prefer to have people review the changes before committing them to trunk. However, the aggregate patch is 87kB in size which makes the changes pretty hard to review. My refactoring consisted of about a dozen smaller and easier to review steps, which unfortunately the patch format doesn't convey. I could have committed those changes directly to trunk and asked for CTR reviews, but since the changes are pretty extensive I'd rather opt for a self-imposed RTC review period. One option for better utilizing our version control infrastructure and avoiding the 87kB patch would have been to implement the changes in a development branch where I could have committed each refactoring step separately. People would have had an easier time reviewing those incremental changes and svn merge would even have helped handle potential overlapping work by others. So, how would you feel if we started using development branches for such purposes? A development branch would always be tied to a single focused Jira issue and located at branches/JCR-nnnn. Only changes related to that issue would be allowed in such a branch, and the maximum lifetime of such branches would be limited (for example to a few weeks). The merge tracking feature in svn 1.5 (our svn server is just being upgraded) could be used to keep the development branches better in line with trunk and also to handle merging of reviewed changes back to trunk. Once the issue is resolved and changes merged to trunk, the development branch would be removed. BR, Jukka Zitting
