[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

new svn conflict resolver status update

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 10 Jun 2016 18:45:37 +0200

I have been regularly working on the new conflict resolver since January.
This is a status update to present the results so far, and what remains
to be done before we can release this.

The code is on trunk, and not on a branch. We could still disable it
without much effort. However, at this point I think this feature is
worth holding the 1.10 release for, until the feature is mature enough
to be released. The lack of tree conflict resolution is a big pain point
for a huge part of our user base (at least for those who stick with
SVN in spite of this problem, for whatever reason). Now that we've got
a real chance to make a difference in that area in the next release,
I think we should.

What is basically ready are:

 - The libsvn_client API (see svn_client.h). I don't see much potential
   for changes there, apart from small cleanups.
   The model used by this API was discussed between myself, Philip, and
   Julian in Slovenia last year, and the 'svn' client has been fully
   converted over (some legacy API fragements remain, but they don't
   affect the resolver code at all).

 - More detailed description of conflicts. Most tree conflicts now describe
   the conflicting incoming and local changes in detail. The descriptions are
   actually trying to explain what happened, rather than basically dumping
   raw working copy meta data to the screen. Users are pointed at revisions
   which contributed to the conflict, and see the author's name in the
   description. I hope this will make communication between developers
   easier when confronted with difficult merge conflicts.
   While doing consulting work for elego clients, I encountered many cases
   where digging up this information to understand where the conflict was
   coming from was harder for users than the actual resolution process itself.
   So I believe fixing this problem alone will be worth it.

 - It is now possible to add new conflict descriptions and resolution options
   to the resolver over time, without changing the public API (except for one
   place, the enum which provides public IDs for options -- but clients don't
   necessarily need this ID to provide support for an option).

 - Some basic resolution options have been implemented for cases like adds
   and deletes. Some even have regression tests.

What needs more work:

 - I'd like to offer graphical descriptions along with textual ones,
   in ASCII art and SVG (for GUI clients).
   A very-nice-to-have feature, not absolutely essential.

 - The resolver attempts to detect incoming moves based on scanning the log.
   This code is very new and experimental. I believe we will need to do a
   lot of testing before we can release this feature to the world.
   The possible edge cases are entirely unclear to me.

 - We need to add more resolution options. The more options we offer,
   the less manual conflict resolution work will have to performed by
   our users. This is really a case where we can't be adding too much,
   no matter how much we keep adding. Since we can always add more options
   in patch releases (no API change required), for 1.10 we should aim for
   a solid set of options with reasonable coverage of common cases.
   We don't have to lean ourselves too far out of the window for 1.10.0.

 - Test coverage is poor. Some XFAIL tests already show that some of the
   existing options don't work in some cases, which is a good thing (from
   the testing point of view). Apart from addressing the existing XFAIL
   tests (hairy merge problems...), we need to add a lot more tests.
   We should have at least one test per resolution option. Ideally, we'll
   test each option in all possible cases it may apply to, i.e. some subset
   of possible combinations of: forward update, backwards update, sync-merge,
   reverse-merge, reintegrate-merge, cherry-pick merge, switch going
   forward in history, switch going backwards in history, file vs file,
   file vs directory, directory vs file, directory vs directory, symlinks,
   externals, add, delete, edit, move, replacement, copy...

I am going to need help especially with the last point, simply because of
the sheer size of the problem space. The existing tests are C test for
libsvn_client, and are using the same API that clients would use.
The python test framework doesn't handle interactive prompting at the
moment so it's pretty much impossible to test the resolver with it.

Understanding the resolver implementation is not necessary when adding tests.
Understanding the resolver API, and understanding how to use the C API to
fudge a working copy into some conflicted state, is sufficient.
If I had a bunch of squirrels to train, just smart enough to know a bit
of C, I'd get a long way with this. But all alone, it's too much work.

I know that we don't have many developer resources right now, and that
many don't have time to write big features themselves these days.
I'd still like to ask for help with the above, because I think if someone
spends the little time they've got on this problem, then that's a very good
investment. With each conflict description we add, and each resolution
option we add, and a test to be certain that it's going to work well,
we're saving our users, some of who are dealing with tree conflicts every
day, a huge chunk of time when they run into the particular conflict.

Even small contributions every now and then would also help with another
problem: I'm starting to feel somewhat lonely around here. While it's great
to have a giant sandbox for myself to play in, the lack of continuous
feedback, which I had usually been receiving for as long as I'm involved
in this project, makes me uncertain about making difficult decisions
and afraid of introducing problems we can't easily fix later on.
Does anyone else feel the same way?
I realize this is normal for a project which is way past its high slope
on the hype curve, but working basically alone most of the time is a lot
less fun than I could have imagined it to be. So there's a slight danger
that I'll lose interest at some point before this project is "done".

Some things are out of scope for this project for me:

 - The resolver assumes that the conflicted node is still in the same
   structural state as the last merge/update/switch operation has left it.
   I don't think this is a huge problem for now. In many cases where
   users make manual changes to the tree structure we're clearing the
   conflict marker anyway.

 - Currently, libsvn_wc provides no new interfaces for atomic resolution
   operations (such as it does for update-move). I'm not going to work on
   this before the above problems have been addressed, if ever.
   There is no risk of inconsistent wc.db states, but automated resolution
   steps could error out at some step in the middle, in which case the user
   gets to deal with the result. However, this is arguably not worse than
   the SVN 1.9 behaviour of not even trying to resolve the conflict in
   the first place.

 - Remembering answers to previous conflicts, to avoid repeated
   interactive conflict resolution across several branches.
   This could probably be done, but I don't have a clear idea of how
   it could be implemented. In any case, it could be added later.

 - "True renames." I believe this is a dead horse, and that SVN needs
   a redesign and an entirely new implementation to support this.
   I'd be glad to be proven wrong, though.
Received on 2016-06-10 18:45:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.