On Sat, Feb 13, 2010 at 10:46:51AM +0100, Bert Huijben wrote:
> I don't think we should set a specific date unless we are willing to cut
> features at that date.
I agree on not setting a date.
> And if we would cut WC-NG, we would have to cut most of the libsvn_client
> stuff too as we implemented svn patch and other features on top of WC-NG.
Well, what is left if you cut WC-NG? Some bugfixes we haven't backported,
and svn patch, HTTPv2, and the first baby steps of an obliterate feature.
Anything else I forgot? Definitely not much.
E.g. svn patch is a nice handy tool, but it's not a killer feature.
The world won't end if it isn't released by next week.
But we really need WC-NG to move Subversion forward, as a whole.
Without WC-NG, we can't make improvements we want, well, need, to make
in future releases.
And I don't think delaying the 1.7 release cycle is comparable to
what happened with 1.5.
In 1.5, merge-tracking was added on top of an *existing* stable code base.
The feature was highly anticipated because it had merits of its own.
It also happened to be hard to design and implement, and took several
point releases until it became stable enough for general use. This is
what caused the delay of the 1.5 release. Along with another part of the
problem, which was that merge-tracking was heavily advertised as Subversion's
new killer feature which would definitely be in 1.5. The expectation was set
by marketing, and no attempt was made to revert this expectation once set.
So people got impatient and some even disappointed.
With WC-NG, we're in a completely different situation.
While we cannot avoid the first problem (hard to implement), we can certainly
avoid the second problem (setting unrealistic expectations).
WC-NG is *not* a "new feature", but a major rewrite of a major part of the
guts of Subversion. If it wasn't for WC-NG, we could declare Subversion
as done, move the 1.6.x code base into CVS-style maintenance mode, and stop
adding features and stop fixing existing major problems.
WC-NG does not have merit on its own, but is needed so that Subversion can
continue moving forward. We will be implementing new features, and fix
currently unfixable problems, on top of WC-NG. If we don't, then WC-NG is
simply a huge waste of time.
So it's well worth giving it all the time it needs to mature and stabilise.
Even if that means not releasing for a while. If it's not mature and usable
when it's finally released, i.e. unfit to serve as a solid base for future
improvements, we have missed our target. I'd rather never release 1.7 and
spend time fixing smallish, and fixable, problems in 1.6 instead. Our users
don't need another unfit or even unfixable working copy implementation.
Of course, we really need more people spending time on WC-NG development.
Which does not necessarily mean that we add more people to the team hacking
the core WC-NG code. For example, once svn patch is releasable, I am planning
to systematically test WC-NG's behaviour when faced with tree refactorings.
I'll report any problems, and add or improve regression tests.
I already encountered and reported a bug with deleting children of copied
directories. I'd like to know if there are more bugs like this hidden in the
design and implementation. With 1.7 and onwards, I'd like to be able to rely
on WC-NG to handle arbitrary tree refactorings really, really well.
This is a must-have requirement for better tree conflict support.
Developers with some time to spare but not enough to dive into core WC-NG
development can make a big difference by doing similar things, making
sure WC-NG is fit for features and improvements they want to add on top of it
(maybe we should make a list of such features and improvements :)
We need to test it thoroughly now (before, not after, 1.7 release) to make
sure the design and implementation does deliver what we need it to deliver.
Stefan
Received on 2010-02-14 18:03:21 CET