Re: Subversion 1.5

On Wed, 14 Mar 2007, Mark Phippard wrote:

> On 3/14/07, Daniel Rall <dlr@collab.net> wrote:
> >
> >At last October's Subversion Summit, we the developers defined 1.5's
> >compelling new feature as Merge Tracking. Let's stand behind our
> >goal. As Greg says, the most realistic way to achieve this is to pull
> >the merge-tracking branch into trunk to catalyze our effort around a
> >compelling new feature. Yes, this is going to break some minor
> >things. But it will also focus our strength-in-numbers on a tangible
> >goal which we will reach much, much more quickly than with a couple
> >developers working independently on a now-mostly-stable branch. The
> >best way to deliver this new feature is to do it together.
> >Personally, I'm ready for this as I was not ready after the Summit
> >(having just become a father).
> >
> >I propose:
> >
> >1. Karl merges sparse-directories onto trunk.
> >2. Dan deals with the conflicts on the merge-tracking branch
> > introduced by Karl's merge.
> >3. Dan merges merge-tracking onto trunk.
> >4. Work continues on these features until at least Merge Tracking can
> > thoroughly handle merge history at any level of a merge target.
>
> I posted something a little like this last week but hearing you Mike and
> Greg all suggest it really causes me to agree. We should try to stay a
> little more focused on the goals we set and see them to completion. The
> features in trunk are useful, but we have told people that 1.5 will have
> these (merge tracking, sparse directories) features and together they make a
> great release.
>
> Dan, these questions are probably for you, since you have led the merge
> tracking effort.
>
> This 1.5 discussion seems to be based on the "fact" that merge tracking has
> 6 more months of development. I do not recall ever hearing you give that
> estimate. We are all developers, we know this could take 6 more months, but
> what do you *think* it is going to take given the current resources working
> on it? I think it would be bad for the community if we did 1.5 now, which
> means a May GA and you guys wrapped the development in June/July. Now we
> have to sit on the feature everyone wants because we just did a release.

I've never said Merge Tracking is 6 months out. With existing
staffing levels, my pessimistic estimate is 3-4 months of development
and testing to put out a release of Merge Tracking which satisifies
most of the "Merging" use cases [1]. This is without any of the
"Auditing" features that Hyrum has been spec'ing out (which I've heard
some people describe as must-haves) [2].

[1] http://subversion.tigris.org/merge-tracking/requirements.html#merging
[2] http://subversion.tigris.org/merge-tracking/requirements.html#auditing

> Do you have a good handle on the work that is left? l have looked at the
> TODO and it seems pretty thorough. If people had time to contribute:
>
> a) Does the work that remains lend itself to parallelization or is it all
> intertwined?

The majority of the remaining work is parallelizable. Here's the
current task list:

http://svn.collab.net/repos/svn/branches/merge-tracking/TODO

> b) With a few more developers tackling parts of this, what sort of timeline
> could we hope for?

With ad-hoc fixes/developement/testing which tend to occur when a
feature is being developed on trunk, coupled with elimination of the
overhead from being on a branch (e.g. merging, conflict resolution,
extra builds, etc.), we could easily pull this into the 2-3 month
time-frame, with a potential upside of delivering some of the
"Auditing" [2] features.

> c) Are you prepared to lead the effort in terms of guiding people that want
> to contribute towards chunks of work that need attention?

Absolutely. And if more people are contributing, I can also commit to
spending more time on itemizing bite-sized tasks in TODO, and
improving the specs.
 
> I sense with some more developers, even more code review and smallish fixes,
> we could talk about branching for the release in just a couple/few months.
> I cannot personally contribute to the Subversion side, but I can start
> trying to use it from Subclipse which might help shake out bugs and validate
> the API.

Putting the merge APIs through their paces from the JavaHL side would
help out with API validation and testing.

> FWIW, I was actually shocked that the users@ list had so many people that
> thought we should wait. We basically said, you can have these new features
> now, and it will not delay merge tracking and a large number of them said
> they would rather we finish merge tracking.

Reading that thread was a big realization for me as well. Merge
Tracking truly makes Subversion into a killer app for some shops, and
allows many others who aren't yet using Subversion to adopt it. It's
amazing how a "check in the feature box" sways people who don't even
need this type of functionality away from commercial products like
Perforce, ClearCase, and AccuRev which do support it. Let's finish
Merge Tracking and continue the trend:

http://subversion.tigris.org/svn-dav-securityspace-survey.html