On Fri, Jun 10, 2016 at 6:45 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
+1
> 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.
Sounds great!
> What needs more work:
...
> - Test coverage is poor...
>
> 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.
I'd really like to help (with tests or otherwise). I know I haven't
been very active lately (some days I'm just trying to stay afloat),
but I'd like to turn that around someday, somehow. I'm still very much
interested in svn in general, and motivated to do what I can to
improve it.
To be honest, being able to use the python test framework would be a
lot more productive for me. Maybe I can look into how to make it
handle interactive prompting? Unless there's a reason why this would
be notoriously difficult to implement?
> 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.
Ack.
> 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".
That would be really unfortunate. I hope you keep hanging in there :-).
I guess you're right that it starts to feel a bit lonely. I feel it
too, even when I'm mostly only lurking on the lists, and occasionally
throwing in a general comment when I can't contain myself ;-).
> 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.
Can't really judge the impact (or a way to solve this), so ... okay.
> - 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.
Does this mean that none of your new resolution options can / will be
applied automatically (hard-coded or optionally by some configuration
or "conflict resolution policy" thing)? Like incoming move upon an
edit?
I'd like this to become available someday, but maybe it can be out of
scope for 1.10, something for later on ...
> - 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.
Meh.
> - "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.
I guess you're right. If it looks like a rename, swims like a rename,
and quacks like a rename, that's probably enough for most users.
--
Johan
Received on 2016-06-13 00:06:06 CEST