[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: Fri, 7 Jan 2011 18:41:56 +0000

On Fri, Jan 07, 2011 at 10:11:29AM -0500, C. Michael Pilato wrote:
> 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.

That will need the new conflict store described in notes/wc-ng/conflict-storage.
We don't have to hold the release on issue #3565.

svn patch is a new feature, and has already passed the original target
feature set anyway. I would have been happy enough with standard unidiff
application without any extras, and now it already does properties, too.

There is one remaining release critical issue in svn patch I am working on.
It opens way too many file handles. Should be fixed soon though, I have
the basics done but still need to debug a little.

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

See http://subversion.tigris.org/issues/show_bug.cgi?id=3563#desc6

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

AFAICT most commits these days fix release critical stuff. I think we're
already on the right track. It would be nicer if everything went faster
of course. But the best we can do is continue banging stuff into shape until
it is enough for release. Philip's list is very helpful.

Received on 2011-01-07 19:42:42 CET

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