Page History

I really support this approach, I think it makes the most sense of any of the strategies out there, however the downside of this approach is how it scales over time. As time goes on and the deviation between the functionalities implemented on the trunk and when they are released increases, the chances of multiple desired functionalities overlapping in some part of the code increases...eventually causing the premature partial release of some functionality. Use of something like that svnmerge.py script that uses svn properties to note what has been merged where and when will address this to some degree, but some system were we know that F(A) references X files and F(B) references Y files...and when we are looking to promote F(B) but not F(A) we can doublecheck that we are not partially promoting F(A)...since svn merges will not pull out the F(A) changes if they are in the same file as F(B).

I see this a lot in volatile development environments coupled with exceedingly tight release cycles.