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

SVN 1.5 Release -- Where are we?

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-11-02 16:30:18 CET

So we are three weeks past our original goal date for branching for
1.5. I thought I'd send an email to gauge where we are and what is

The Good:
Lots of good changes have come in. Support for relative externals,
interactive resolution for prop conflicts, the copy-on-update feature,
multiple revision ranges on merge API, previous release compatibility
improvements etc. At the same time, people have been finding and
fixing bugs at a pretty good pace. Likewise the Buildbot was all
green for a while and is in pretty good shape in general.

The Bad:
It is not really bad, but with all the bug fixing it is hard to know
where we are right now since we do not know what bugs we will find
next. It was a little easier to predict a date when we had a specific
list of features we had to finish.

The Ugly:
It seems unlikely we will have a GA release before end of year. We
would have to get RC1 out in days to have any chance and I do not see
that happening.

So where do we go from here? I think the best thing is to get a
handle on what we need to do still and try to set a new realistic
estimate for RC1. I'd like to hear from people before I make any
attempt to do that, and I'd love to just hear some others chime in on

The CollabNet engineers had a quick call this AM to catch up on what
we are all working on. I think there are two big merge
tracking-related issues that need to be solved before 1.5. Of course
there are also some general merge tracking bugs that are in the issue
tracker and being worked on as well. Here are the two big issues

2897: http://subversion.tigris.org/issues/show_bug.cgi?id=2897
Reflective merges:

This is a common situation that SVN does not handle well today. You
make a feature branch, periodically synch it with trunk, and
eventually want to merge back to trunk. Kamesh has some ideas on how
we can make some improvements to this process but it will require some
back-end schema changes. Karl and Kamesh have been discussing this in
another thread:


The other issue is nominally issue: 2875.

Mike Pilato has some ideas about how we could use the repository
history to determine the implied mergeinfo for an item the first time
it is needed (rather than needing to initialize an svn:mergeinfo
property when something is copied). This will have two benefits:

1) Existing repositories will already have some merge tracking
intelligence without needing a dump/load. Likewise, a cvs2svn
conversion would also have some of this automatically. (What it would
get is that a branch would know that it contains the revisions from
its copy source).

2) We should be able to solve the problem where a WC to WC copy/move
needs to contact the repository. We should be able to do away with
the -g option on these commands and just make them work right.

This change should make merge tracking work better and solve some of
these problems we have been dealing with. It also sounds like it
slides into our existing design a little better than it might sound on
the surface.

I do not think this change impacts the svnmerge.py migration at all.
The properties would still just convert to the svn:mergeinfo format.

I am not sure if this has any potential impact on the log/blame -g
options. It might depend on how directly they rely on the SQLite data
as opposed to some other API.

There are 18 issues total, most of the same ones that have been out
there, 12 of them are related to merge tracking. I'd encourage
everyone if they have some spare cycles to just help us get closure on
this release. Review some code, do some manual testing, close out
some issues, start working on CHANGES etc.

As before, if there are any other issues lurking out there, please
raise them here and/or the issue tracker so that we are all aware of
them. Don't sit on a bug or forget to report it.

Finally, I am not sure how, but I think we still need to get an idea
on when and how we can get this to RC1 stage. We all want to get
there, let's figure out how to make it happen.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 16:30:28 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.