Neels J. Hofmeyr wrote:
>
> Hyrum K. Wright wrote:
>> Hi all.
>>
>> As has been discussed on IRC, dev@, and at the summit last week, we're shooting
>> for a 1.6.0 release toward the end of December, approximately 6 months after
>> 1.5.0. Given that goal, and our typical release cycle, that would mean
>> branching near the end of October/beginning of November. So I'm pegging the
>> branch date at Nov. 5, 1700 UTC.
>>
>> I'll follow this up with my standard disclaimer: this date isn't set in stone
>> (more like quick drying concrete). If there are serious and valid concerns, we
>> can push the date back a week or so, but I'm hesitant to go any farther than that.
>>
>> In the meantime, please try and be a little conservative about what makes it
>> into trunk, so that it's pretty stable when we branch.
>
> Yes, I have a question about that. I tried to use diff to tell
> tree-conflicts detection whether two dirs are the same. Thus I found diff
> doesn't support most of the cases we need for tree-conflicts.
>
> So I span off into trying to enhance diff --summarize, finding out that even
> plain diff for a "supported" case is very much broken.
>
> To make a long story short, in order to fix diff in a sane way and to then
> be able to detect tree-conflicts properly, I would need to extend the
> (public) diff callbacks API, as in changing callbacks signatures, with minor
> repercussions through all code that uses the diff callbacks (e.g. merge).
>
> So there's two sides:
>
> a) It would be nice to have the new API change in 1.6; 1.6 already changes
> the same structure in a simpler way (svn_wc_diff_callbacks2_t ->
> svn_wc_diff_callbacks3_t), and we would avoid having to change it to
> svn_wc_diff_callbacks4_t right in the next release.
>
> b) I would probably have to hurry to get the stuff working.
>
> What do you say, "try and we'll see if it makes it in", or is it a
> resounding "nah... forget it"?
I would say do what you can and we'll see if it make it in. The Nov. 5 date
does *not* mean perfect code by the time we branch. It *does* mean that the
feature is reasonably complete, and can be stabilized over the course of the
next few weeks.
In this case, if you've got a pretty good feel for the API, I'd go ahead and get
that in, with a big disclaimer saying that parts of it may be unimplemented at
this time (and perhaps a runtime check as well). Much like wc-ng, some code is
better than no code in a lot of instances, and big features can be released
incrementally.
-Hyrum
Received on 2008-10-22 16:49:30 CEST