I am reticent to comment to the developer community directly (and you can see it has only happened a couple of times in 10 years), but as someone who's been focused for the life of Subversion on its implementation for enterprises and has been the source of impetus for much of what CollabNet has contributed post 1.1 (including to some extent the push to implement merge tracking as the key feature of 1.5); I feel compelled to speak to this issue.
Merge tracking was implemented out a need from enterprises to create an audit trail and to have the tool make merging require less user knowledge to execute (within obvious limits). It was a logical next step to going beyond the original focus (being a viable replacement for CVS) to becoming a tool that supported the additional needs that enterprises have that open source development either doesn't have or doesn't have to the same extent. While in hindsight I still regret not understanding the tree conflict issue and getting it addressed first, there is no question that the presence of this functionality has opened up a larger community of users for Subversion than it could have had without it. For all its warts (and believe me I appreciate the extent of its warts), it has made a HUGE difference in Subversion's adoption. It is also important to note that there has been a significant shift over the history of this project from being very open source focused and heavily utilized for that purpose to being largely utilized by enterprise customers. That inherently brings many use cases that those focused on open source development don't face and commonly struggle to appreciate (I recall originally educating committers on what tree conflicts were and why fixing them was critical to enterprises). That is completely understandable, but the project must provide for its user/customer base and for Subversion that is enterprises. It must also be understood that this customer base is not appropriately represented by voices in the community because of a reluctance by many enterprises to be public about their use of open source technology (or frankly even proprietary technology though in that case the issue of representation is handled very differently). There are some who've commented that there must not be pent up demand for 1.7 because there isn't a huge outcry for its continued delay. This is a misinterpretation. Enterprises desperately want to see Subversion move forward and are frustrated with the amount of time that 1.7 has taken, but again, the users in those enterprises are constrained by those enterprises from publicly expressing that. Putting forth designs and functionality suggestions are going to get the same responses (i.e., more open source development feedback) even though enterprises have strong opinions. This list is not going to be indicative, at all, of what the user community necessarily feels about topics like this (beyond the obvious, we want merging to be faster and work better). I see a lot of dismissing of various pieces of existing functionality that I don't think reflect what the true user base uses and requires. Simplicity is a wonderful goal and wherever possible it should be pursued, but Subversion should not abandon its users just because something is complex as long as it is achievable. As has been suggested before, best practices should be trumpeted (I know we do at CollabNet) and potentially even enforced when an organization chooses to enforce it. Removing functionality is something that must not be taken lightly and must be done only after diligent efforts to truly understand the will of the user community. I have great admiration for Subversion's developers past and present, but with the widespread use of Subversion today, impactful changes to functionality need to be taken cautiously and with feedback sought at the idea, design, and implementation levels. There are many features that bring value to some, but others will want to be able to opt out of those features (which is to their credit as many might just try to block the features they don't want to see used in their enterprise). The ability to do that I see as a requirement to many things that people want to implement and for me, a precursor to adding other functionality. I am not opposed to new approaches and ideas to merges and merge tracking. I welcome new input on these topics and look forward to improvements as a result of them. I am opposed to dropping functionality without extended efforts to get feedback (not by just asking the members of this email list) and without proven returns that include having whatever functionality is determined to be absolutely required. I am also a HUGE proponent of branching for this work as with most of what is non-trivial development. Users are not happy with a release that will take at least 28 months. We heard that cry when 1.5 took 21 months and people swore that would not happen again. This project must find a way to utilize branching and do reviews on branches versus trapping releases by having to complete large pieces of functionality because they are being developed on the trunk. Releases must come at a more predicable and reasonable pace. I've had to even respond to whether Subversion has sunsetted due to the long wait for this release. I know this is not a popular idea, but we can't expect different results by doing things the same way. Thanks for listening, Bob Jenkins Director, Subversion Services CollabNet
