On Tue, Aug 6, 2013 at 10:40 PM, Fredrik Orderud <forderud_at_gmail.com> wrote:
> 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.
>
> 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.
>
Hi Fredrik,
Thanks for the patch. Don't be put off by the lack of response, some
people are on holiday (I'm writing this response from the side of a
swimming pool myself :-)). So it might take a couple more days /
weeks.
I've just taken a quick look at your patch (I have not tested it (away
from my development computer) to see if it fails for the right
reason). Overall it seems pretty good, but I think I'd make the test
expectations a little less fragile, by only using the minimal part of
output that needs to be verified (e.g. only 'C file\n' or something
like that).
Have you ran the test yourself, and verified that it (x)fails for the
right reason (by examining the test output)?
Apart from that, I don't have much feedback, but I'm only tangentially
involved in this feature / discussion anyway. Perhaps some of the
other developers have more to add ...
--
Johan
Received on 2013-08-09 16:36:33 CEST