You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2016/06/10 16:45:37 UTC
new svn conflict resolver status update
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.
Re: new svn conflict resolver status update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jun 15, 2016 at 9:29 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jun 15, 2016 at 06:56:56AM +0000, Markus Schaber wrote:
>> Hi,
>>
>> > -----Original Message-----
>> > From: Johan Corveleyn [mailto:jcorvel@gmail.com]
>> > Sent: Tuesday, June 14, 2016 10:15 PM
>> > To: Johan Corveleyn; Subversion Development
>> > Subject: Re: new svn conflict resolver status update
>> >
>> > On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <st...@elego.de> wrote:
>> > > On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
>> > >> 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?
>> > >
>> > > One reason which makes this difficult is that 'svn status' and 'svn info'
>> > > do not show the new conflict descriptions. They still show the same
>> > > data as they did in 1.9. This allows me to avoid updating test
>> > > expectations for a ton of existing python tests.
>> >
>> > Ah okay. I suppose 'svn status' and 'svn info' will show the new conflict
>> > descriptions eventually, but just not right now, and that this might be a
>> > moving target (the exact wording etc.) for a while.
>> > Okay, that may make it difficult to program tests against.
>
> I don't see a reason for changing 'svn status' and 'svn info'.
>
> Creating better descriptions requires accessing the repository.
> It's fine for 'svn resolve' to do this, but 'svn status' and 'svn info'
> should remain offline operations.
Ah, I see. So 'svn status' and 'svn info' (obviously) only have very
basic (offline) information about the conflict, and know little on
resolution possibilities. That's why we have 'svn resolve', which does
all that work (including contacting the repository. And it's 'svn
resolve' (in all its different variations) that needs most testing.
That's where your other paragraph comes in:
> So the python tests would have to run 'svn resolve' and parse the description
> of the conflict from English sentences. This could be done, but it's not
> going to be easy to maintain. I expect us to keep tweaking and refining
> conflict descriptions over time.
Okay, understood.
--
Johan
Re: new svn conflict resolver status update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 15, 2016 at 06:56:56AM +0000, Markus Schaber wrote:
> Hi,
>
> > -----Original Message-----
> > From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> > Sent: Tuesday, June 14, 2016 10:15 PM
> > To: Johan Corveleyn; Subversion Development
> > Subject: Re: new svn conflict resolver status update
> >
> > On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <st...@elego.de> wrote:
> > > On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
> > >> 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?
> > >
> > > One reason which makes this difficult is that 'svn status' and 'svn info'
> > > do not show the new conflict descriptions. They still show the same
> > > data as they did in 1.9. This allows me to avoid updating test
> > > expectations for a ton of existing python tests.
> >
> > Ah okay. I suppose 'svn status' and 'svn info' will show the new conflict
> > descriptions eventually, but just not right now, and that this might be a
> > moving target (the exact wording etc.) for a while.
> > Okay, that may make it difficult to program tests against.
I don't see a reason for changing 'svn status' and 'svn info'.
Creating better descriptions requires accessing the repository.
It's fine for 'svn resolve' to do this, but 'svn status' and 'svn info'
should remain offline operations.
> Maybe we could provide a way for the tests to read the description strings
> for each situation, so the test can adapt to different descriptions?
There is no real benefit in testing the descriptions.
The descriptions should make sense to humans, not machines.
What really needs automated testing are the various resolution options.
RE: new svn conflict resolver status update
Posted by Markus Schaber <m....@codesys.com>.
Hi,
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: Tuesday, June 14, 2016 10:15 PM
> To: Johan Corveleyn; Subversion Development
> Subject: Re: new svn conflict resolver status update
>
> On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <st...@elego.de> wrote:
> > On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
> >> 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?
> >
> > One reason which makes this difficult is that 'svn status' and 'svn info'
> > do not show the new conflict descriptions. They still show the same
> > data as they did in 1.9. This allows me to avoid updating test
> > expectations for a ton of existing python tests.
>
> Ah okay. I suppose 'svn status' and 'svn info' will show the new conflict
> descriptions eventually, but just not right now, and that this might be a
> moving target (the exact wording etc.) for a while.
> Okay, that may make it difficult to program tests against.
Maybe we could provide a way for the tests to read the description strings
for each situation, so the test can adapt to different descriptions?
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Re: new svn conflict resolver status update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <st...@elego.de> wrote:
> On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
>> 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?
>
> One reason which makes this difficult is that 'svn status' and 'svn info'
> do not show the new conflict descriptions. They still show the same data
> as they did in 1.9. This allows me to avoid updating test expectations
> for a ton of existing python tests.
Ah okay. I suppose 'svn status' and 'svn info' will show the new
conflict descriptions eventually, but just not right now, and that
this might be a moving target (the exact wording etc.) for a while.
Okay, that may make it difficult to program tests against.
> So the python tests would have to run 'svn resolve' and parse the description
> of the conflict from English sentences. This could be done, but it's not
> going to be easy to maintain. I expect us to keep tweaking and refining
> conflict descriptions over time.
>
> Whereas the public C API is already "frozen" so it's possible to write
> a test once and have it working "forever". The hard part is all about
> getting the working copy into a conflicted state.
> The steps beyond that is almost identical in each test:
> - resolve the conflict (same API call everywhere expect for the option ID)
> - make sure the working copy has the expected status
>
> So I would guess that while the C tests are a bit more work to write
> they will pay off much better during long term maintenance.
Okay.
> Caveat: The interactive conflict menu is not automatically tested.
> But it never has been. And while some small mistakes did slip into
> released menu code in the past there hasn't been a serious problem.
>
>> 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?
>
> The API allows the client to select an option so the decision is entirely
> up to the client. Different clients could do different things here.
Ack.
>> I'd like this to become available someday, but maybe it can be out of
>> scope for 1.10, something for later on ...
>
> I'd like to see how interactive resolution works out. I don't want to
> cut the user out of the loop, especially in situations where we use
> heuristics as we do with incoming moves. Perhaps later, once certain
> options have "proven" themselves, and/or if many people ask for it,
> we could execute certain options by default. But I believe the default
> should be interactive prompting, at least for now.
>
> For 1.10 we could try to add a configuration option somewhere in
> ~/.subversion which allows users to pre-select options for some conflicts.
> It's not trivial though, because the configuration directives would need
> to match a particular conflict and I'm not sure how exactly that could be
> expressed in the 'ini'-style syntax of our existing config files.
> It also pushes a configuration burden on our users. Instead of answering
> questions they'll be editing the config.
>
> Or we could add a single toggle for 1.10 that enables 'smart' resolution which
> would pick certain options automatically where we believe it to be appropriate.
> This could either be some kind of 'svn resolve --be-smarter-than-me' command
> line option, a configuration file option, or both.
> This would be pretty easy to implement, but we'd have to make good guesses
> as to what is a 'smart' thing to do in a given situation.
> And we'll have to consider what could happen when heuristics get it wrong.
Okay, sounds like a good approach. I don't have anything to suggest
for this right now.
--
Johan
Re: new svn conflict resolver status update
Posted by swdev <sw...@gmail.com>.
Here's a though of the top of my head
Say, in a given scenario, you have resolution options A, B, C and D
displayed as
A) xxx B) xxx C) xxx D) xxx : suggest C:
Where suggest C means that the suggested resolution would be option C.
You could then have an '--use-suggested-resolution' option that would
automatically use the suggested resolution, if there is one. If there is no
suggested resolution, svn would still prompt the user.
Re: new svn conflict resolver status update
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
> 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?
One reason which makes this difficult is that 'svn status' and 'svn info'
do not show the new conflict descriptions. They still show the same data
as they did in 1.9. This allows me to avoid updating test expectations
for a ton of existing python tests.
So the python tests would have to run 'svn resolve' and parse the description
of the conflict from English sentences. This could be done, but it's not
going to be easy to maintain. I expect us to keep tweaking and refining
conflict descriptions over time.
Whereas the public C API is already "frozen" so it's possible to write
a test once and have it working "forever". The hard part is all about
getting the working copy into a conflicted state.
The steps beyond that is almost identical in each test:
- resolve the conflict (same API call everywhere expect for the option ID)
- make sure the working copy has the expected status
So I would guess that while the C tests are a bit more work to write
they will pay off much better during long term maintenance.
Caveat: The interactive conflict menu is not automatically tested.
But it never has been. And while some small mistakes did slip into
released menu code in the past there hasn't been a serious problem.
> 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?
The API allows the client to select an option so the decision is entirely
up to the client. Different clients could do different things here.
> I'd like this to become available someday, but maybe it can be out of
> scope for 1.10, something for later on ...
I'd like to see how interactive resolution works out. I don't want to
cut the user out of the loop, especially in situations where we use
heuristics as we do with incoming moves. Perhaps later, once certain
options have "proven" themselves, and/or if many people ask for it,
we could execute certain options by default. But I believe the default
should be interactive prompting, at least for now.
For 1.10 we could try to add a configuration option somewhere in
~/.subversion which allows users to pre-select options for some conflicts.
It's not trivial though, because the configuration directives would need
to match a particular conflict and I'm not sure how exactly that could be
expressed in the 'ini'-style syntax of our existing config files.
It also pushes a configuration burden on our users. Instead of answering
questions they'll be editing the config.
Or we could add a single toggle for 1.10 that enables 'smart' resolution which
would pick certain options automatically where we believe it to be appropriate.
This could either be some kind of 'svn resolve --be-smarter-than-me' command
line option, a configuration file option, or both.
This would be pretty easy to implement, but we'd have to make good guesses
as to what is a 'smart' thing to do in a given situation.
And we'll have to consider what could happen when heuristics get it wrong.
Re: new svn conflict resolver status update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Jun 10, 2016 at 6:45 PM, Stefan Sperling <st...@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