[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 07 Jan 2011 10:11:29 -0500

On 01/06/2011 06:32 PM, Stefan Sperling wrote:
> On Thu, Jan 06, 2011 at 03:41:42PM -0500, C. Michael Pilato wrote:
>> 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.

Cool. What does this mean for the following roadmap.html item:

   svn patch (and related svn diff improvements) / In Progress /
   Feature-complete. Only item left is issue #3565, which depends
   on conflict storage.

>> WC-NG file externals? Maybe... but what remains to be done?
> AFAIK nothing has been done on that.

Do you have any idea what it even means? Is there some pointer we can drop
into roadmap.html?

> 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.

Oh, of course not. Branching is largely symbolic, but also is designed to
reduce the amount of code churn that isn't specifically aimed at the release
but would otherwise inevitably affect it. Perhaps that's not so terribly
necessary for us these days -- it's not like there are tons of active
committers poised to drop big new feature bombs into the source code or

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

Received on 2011-01-07 16:12:19 CET

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