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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
