On 11/2/07, Mark Phippard <firstname.lastname@example.org> wrote:
> 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.
The work I've been doing recently (especially on depth and
copy-on-update) has led me to believe that we need a lot more tests of
those features, especially some of the more corner-case issues (using
--depth with commands other than update, using copy-on-update with
things like eol/keyword substitution and replaced files).
I encourage people to add to the Python test suite, but I'd also be
happy to convert shell scripts for cases like this into Python tests.
Manual testing is good too!
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Nov 2 17:13:55 2007