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
Received on 2011-07-12 21:32:41 CEST