Fredrik Orderud wrote on Tue, Aug 06, 2013 at 22:40:02 +0200:
> On Tue, Aug 6, 2013 at 3:19 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>
> > FYI, another user complained about this on the users list (Fredrik
> > Orderud, CC'd) [1]. He has filed issue #4405 [2]. Perhaps some of the
> > interested parties here can take a closer look? Or maybe Fredrik or
> > anyone can start / continue discussion to go towards a detailed
> > specification of the behavior of such an optional 'strict' flag or
> > something like that ...
> >
> > (no specific interest myself, just trying to tie some loose ends together)
> >
> > [1]
> > http://mail-archives.apache.org/mod_mbox/subversion-users/201308.mbox/%3CCAHGmiisrngb1sogdLhKkY+9ePuNqVjZ8V7J_LyfAkxezZ54fJw@mail.gmail.com%3E
> >
> > [2] http://subversion.tigris.org/issues/show_bug.cgi?id=4405 (Merge
> > order affects final result for repeated added & deleted changes)
> >
>
> I've now written an XFAIL test for merging the same change change twice.
> Patch attached. The test fails as expected due to the lack of conflict.
> This is the first test I've ever written for subversion, so there are
> probably some improvement opportunities. I suspect that one weak spot is
> that a "greek-tree" structure is generated without being used in the test.
> Also, comparison of console output for merge results feels a little fragile.
>
Yes, agreed on both points. You could use A/mu instead of creating a new
file, and use one of the svntest/actions.py helpers that parse the
output of merge/status instead of depending on the exact byte-by-byte
expected output. More below.
> Please let me know if there are any comments to the patch, and I'll do my
> best to improve it. Otherwise, it would be great it the test could be
> integrated, so that issue #4405 can receive some test coverage.
>
> Thanks in advance,
> Fredrik
Please use text/plain MIME type. This makes review easier. Usually
*.txt extesion achieves this.
I think the patch is correct *if* we agree that "Merge the same change
twice" should raise a conflict. Prior discussion in this thread
indicates that in present svn that scenario is explicitly decided not to
be a conflict. Therefore, I am not going to commit this patch.
I think the best thing to do is to attach it to the issue tracker on the
issue tracking Julian's suggestion of a "strict conflicts" mode. That
way, we can apply the patch once we start implementing the "strict"
mode. (We tend not to change our svntest/*.py interfaces that much, so
I wouldn't be concerned about bitrot.)
So, in summary: thanks for the patch, I think it's correct, but I'm not
going to apply it for the reasons above.
Does that make sense?
Thanks again,
Daniel
Received on 2013-08-09 17:18:45 CEST