Fredrik Orderud wrote on Tue, Aug 06, 2013 at 22:40:02 +0200: > On Tue, Aug 6, 2013 at 3:19 PM, Johan Corveleyn <jcor...@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_lyfakxezz54...@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
