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
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.
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.
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
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
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
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
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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 2 16:30:28 2007