On 11/2/07, Mark Phippard <markphip@gmail.com> 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
> left.
>
> 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
> that.
>
> 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
> though"
>
> 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:
>
> http://svn.haxx.se/dev/archive-2007-11/0046.shtml
>
> The other issue is nominally issue: 2875.
> http://subversion.tigris.org/issues/show_bug.cgi?id=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!
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 17:13:55 2007