[Ben & Mike in Cc: Skip to the very end of this mail.]
On Wed, Oct 22, 2008 at 01:46:17AM +0200, 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"?
diffcallbacks3 only add dir_open and dir_close callbacks to the public
API. So in any case, the public API as-is (give or take open_dir and
close_dir) would have to be in any 1.x release.
So I'd say:
Forget about directories for now, fix up the UI in trunk before the
branch (really!), and plan to add support for directories in 1.7.
If necessarry, remove any tree conflict detection for directories from
trunk before 1.6 is branched -- we don't want it in a release if it's
only half-baked.
Tough, but if things go as planned 1.7 will be out June next year,
which is not that far away.
And tree conflicts on files will already help people a lot -- or make
them complain, I'm exited to see what users will complain about when
they first run into tree conflicts -- we'd better polish the UI before
release, and make sure the book explains tree conflicts well enough
for people who have never even thought about this problem to be able
to deal with the situation in a meaningful way.
I'm afraid I myself won't have much time to contribute any meaningful
tree-conflicts work though, finally gotta flesh out my Master's project
proposal, deadline for that is also around 5th of November :/
Still: Mike, Ben, I'd happliy review and/or extend any
tree-conflict-related material for the svnbook.
Don't hesitate forwarding stuff to me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-22 11:45:13 CEST