On Tue, Jan 24, 2017 at 12:20 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> Another update on the new conflict resolver:
> We have 36 conflict resolver tests, all of which PASS.
> I have updated the wiki page about conflict tests accordingly:
> The 36 tests we have still do not cover much of the overall problem space.
> However, our tests cover the existing conflict options. I guess we will be
> expanding our set of tests whenever new options get added and user-reported
> bugs get fixed. I don't see much value in adding additional regression tests
> at this point. Rather, I think we need to get the resolver out into the hands
> of users to see if it meets their expectations during day-to-day operation.
> Apart from tests, there are other important points marked with [X] in:
> Among those, only one is left unresolved:
> - Markup in test descriptions (for GUI clients). (Suggested by ivan)
> Since I am not a GUI developer I will leave this task to somebody else who
> is more competent in that area. Of course, I would be able to support such
> an effort and help with making design decisions and getting an implementation
> worked out.
> Other unresolved items mentioned in this file are:
> - Recommended resolution option(s)
> (includes support for using the conflict resolver with --non-interactive)
> - Working copy operations are not atomic
> - Resolution scripts (aka custom user-defined resolution options)
> - Issue with multirange merge
> I myself do not plan to address these items for the 1.10.0 release.
> I would be fine with releasing the current implementation as 1.10.0 and to
> fix bugs and add more resolution options during the 1.10.x release series.
> The current feature set already provides huge improvements over 1.9.
> Further improvements, which require API changes, can be postponed to 1.11.
> I would like to get an 1.10.0 alpha1 released in February. Unless I hear
> objections I will start rolling this alpha release from trunk and call a
> vote on it soon.
That's great news, Stefan, and I bow to your perseverance on this. Great work!
I'm sorry I haven't automated generating the table on the
TreeConflictTests wiki page, causing tedious manual work for you. But
I'm glad the page is still useful.
I'll try to do some more manual experiments with a trunk build. I'm
all for rolling an alpha release, or in any case doing what we can to
get user feedback on this.
I'm wondering if we should also create a table / documentation listing
the supported conflict options, and what they do. Or is this more or
less the same as the TreeConflictTests table, since as you said it
covers the existing conflict resolution options?
Received on 2017-01-24 23:42:18 CET