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