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.
Noted.
>> 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
anything.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-01-07 16:12:19 CET