On Wed, Jun 15, 2016 at 06:56:56AM +0000, Markus Schaber wrote:
> Hi,
>
> > -----Original Message-----
> > From: Johan Corveleyn [mailto:jcorvel_at_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 <stsp_at_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.
Received on 2016-06-15 09:29:51 CEST