Re: new svn conflict resolver status update

2016-06-15 Thread Johan Corveleyn
On Wed, Jun 15, 2016 at 9:29 AM, Stefan Sperling  wrote:
> On Wed, Jun 15, 2016 at 06:56:56AM +, Markus Schaber wrote:
>> Hi,
>>
>> > -Original Message-
>> > From: Johan Corveleyn [mailto:jcor...@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  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

2016-06-15 Thread Stefan Sperling
On Wed, Jun 15, 2016 at 06:56:56AM +, Markus Schaber wrote:
> Hi,
> 
> > -Original Message-
> > From: Johan Corveleyn [mailto:jcor...@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  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.