[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What stands between us and branching 1.7?

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 6 Jan 2011 23:32:13 +0000

On Thu, Jan 06, 2011 at 03:41:42PM -0500, C. Michael Pilato wrote:
> I'm sorry if I asked this before -- I've been asking individual folks for
> over a month now, but I can't quickly find a public broadcast thread about
> it, at least -- but I've been wondering lately:
> What, exactly, stands in the way of us branching for 1.7 stabilization?
> ra_serf stabilization? No... that's fairly well taken care of, and would
> fit perfectly within in the scope of post-branch work anyway.
> WC-NG conflict storage? No... last I heard, we were going to ship with what
> we have today.

I think we decided what we have today is fair enough to be released
and then built upon in subsequent releases.

> WC-NG file externals? Maybe... but what remains to be done?

AFAIK nothing has been done on that.

> Optimizations and performance stuff? Sounds like stabilization to me.

I am intending to continue working on performance, especially wrt
reducing the amount of sqlite queries we issue. This may still affect
APIs, so I don't think it's worth branching beforehand. Given my current
holiday and work schedule I cannot give an ETA though. I am making small
steps mostly.

As it stands, the libsvn_wc code is now using sqlite storage but is otherwise
still structured a lot like 1.6.x (we're doing per-node queries everywhere
and that is slow). There seems to be no big picture yet on how to
really get performance up. As I understand the situation, the original
designers of wc-ng expected that the current way of doing things would
perform well enough to be releasable. We now found that's not the case.
So we need to put more work into 1.7 to make it attractive for users
to upgrade to. Releasing in the current state would be a bad idea IMO.

> Besides "the tests are passing", what -- if any -- acceptance criteria have
> we established for this release to help guide us in this process? "Must not
> regress performance-wise versus 1.6?" Something more? Something else?

At this point I'd be happy with that criteria.

A general note on branching: I think we have for a while now been
stabilising on trunk, and as far as I'm concerned we can continue
to do so until we consider trunk releasable. I don't think branching
will magically make the release appear any faster.

Received on 2011-01-07 00:33:01 CET

This is an archived mail posted to the Subversion Dev mailing list.