Stefan Sperling wrote on Thu, 26 Mar 2020 11:15 +0100:
> On Thu, Mar 26, 2020 at 01:10:25AM +0300, Anton Shepelev wrote:
> > Daniel Shahaf:
> > > however, I don't think the lack of these distinctions is
> > > necessarily a blocker. It just means we need to be more careful
> > > about not writing automation that will help some cases and
> > > backfire in others.
> >
> > Certainly not. I still hope that my proposal can be made safe.
>
> There is a way to find out, but it requires some work:
>
> Write a patch that implements your proposal.
>
Rather than a proper patch, it might be easier to start by writing
a prototype that uses shell, or Python, or whatever else to compute the
needed information, and run tests on that. If nothing else, this
approach will divide and conquer Anton's learning curve.
> And then ensure that all tests in Subversion's regression test suite
> keep passing with that patch applied and with the URL argument removed
> from every merge command that runs a sync-style merge throughout the
> entire regression test suite.
Huh?
I don't see any sense in removing the source arguments from _all_ sync
merges. That will predictably fail several tests (for one, any test
that uses a peg revision on the source URL).
If you'd meant to ask Anton to remove the source URL in cases where it
ought to be guessable according to the behaviour specification of the
change proposed¹, that'd be another thing — but I still think that might
be too big a chunk of work for us to ask for as a smoke test.
¹ That is, when the source URL is equal to the copyfrom path of the
merge target and has a peg revision of HEAD.
> I'm confident that the regression test suite is comprehensive enough to
> catch any problems and if needed inspire further discussion about those
> problems in detail. It's hard to thoroughly evaluate your idea without
> knowing which of the test cases will break and why.
>
Stefan, this is a strawman. None of the existing tests will break,
because «svn merge» without positional arguments is currently a syntax
error. Making a previously-erroneous syntax meaningful _can't_ cause
regressions.
Incidentally, that's also the reason I think running tests on a patch
implementing this is unlikely to be an effective way to find potential
issues with the design. Running tests is a good way to smoke tests
changes to implementations of existing interfaces — which isn't the case
here. If there _are_ issues with the proposed feature, I don't think
«make check» will find them.
> I've used the test suite many times to try out random ideas I've had.
> This approach works really well and is often quite enlightening!
>
> In any case, what you're asking for implies that at a minimum either you
> or someone else would have to invest time into actually doing the above
> work in order to verify your idea and make it happen, regardless of which
> potential problems are being discussed now.
Yes, this feature won't happen unless someone invests time in making it
happen — but let's not discourage people from discussing feature ideas
even if they may not personally have time to implement them.
Discussions are just as useful a contribution as patches.
Daniel
Received on 2020-03-26 22:21:18 CET