Re: "Subversion 1.5, Technology Preview"

Eric Gillespie wrote:
> I propose that we take 1.5.x through the full release process,
> just as we did with prior releases, and release it to the world,
> and lifting our discouragement of packaging. But, let's:
>
> - advertise it as a technology preview
>
> - be explicit and honest about the status of the new features,
> and our plans for 1.6[1]
>
> - declare up-front that we may break compatibility *with the new
> features* in unprecedented ways in 1.6 (but maintain ABI
> compatibility?)

As I examine your list of complaints about this release (some of which are
well-founded, some of which I think are just FUD), and consider some of the
root causes, there are two that come to mind:

First, Subversion is well past the mark of basic usability suited to Most
People. As such, our volunteer developers, SoC coders, etc. are not likely
to be scratching universal itches because within the realm of things we can
reasonably fix, there aren't all that many universal itches. That means
folks are left to scratching their own itches, which in turn leads to a
smaller number of eyes on any given feature, and a general sense of
not-well-testedness overall. I think that's sorta the way the cookie
crumbles when you're now 4-5 years past the point where Subversion was "good
enough".

Secondly, many of the shortcomings you've expressed about 1.5 features (and
other things we'd like to do but can't -- some of those universal itches
that *do* remain) owe to some fundamental aspects of our model, mostly our
working copy model with its scattered admin directories, and in some aspects
of our repository model (lack of renames as first-class citizens, etc.).
Maybe the real problem isn't that we're becoming sloppier coders or worse
testers and so on. Maybe the problem is that Subversion is nearing the
boundaries of what can be reasonably accomplished with its current model.
Maybe it's time to rethink the model. Maybe we should get 1.5 out the door,
roll 1.6 with tree conflicts detection and Kamesh's merge algorithm
improvements and whatever other mostly-done things can be finalized and
delivered in under 6 months, and then seriously take on the challenge of
Subversion 2.0.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand