See discussion in
https://bz.mercurial-scm.org/show_bug.cgi?id=6163. D9130 reminded me
of this idea.
Details
- Reviewers
marmoute pulkit - Group Reviewers
hg-reviewers
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
Regardless of the issue6163 question, simply dropping the tracking or removed files seems wrong and will introduces bug (eg: we can end up merging a "dead" file history with a fresh file history, picking the "dead" one). So we cannot do that.
minimal description of the case I am talking about below.
o → X should be copied from B, not A | \ o | delete X | | o | rename A to X | | | o rename B to X |/ o
We would also need more code for simpler case:
4 → copy tracing from 1 to 4 should not list X←Y | \ 3 | delete Y |/ 2 rename X → Y | 1 …
I added that test as a parent of this patch (D9171). It passed before and after this patch. Did I not write it down correctly?
I've exported the current state so you can see the differences on the entire test suite, but I plan to make it configurable so it can be rolled out slowly. Maybe I'll make a copy of test-copies-unrelated.t then, or maybe I'll add another #testcases follow nofollow to the file.
My previous, larger comment got lost. It contained other tests cases.
I do not have time re-type my full comment (phabricator eating comment is very upsetting). Please stop pushing this diff forward, it is broken.
Weird, never happened to me.
Please stop pushing this diff forward, it is broken.
Well, you'll have to provide at least some proof of *what* is broken then.
test
Hmm, I must have run tests on another version of something, because the test now fails for me with this patch, which makes sense. I think I once had a check in the code merging the copy dicts from each merge parent to make it ignore copies that had been deleted (like in this test case), but it was really slow. I took a quick look but I didn't find it and it's getting late here.
IIUC changes are planned on this one as the test case mentioned fails with this patch. Kindly correct me if I am wrong.
Yes, I'll see if I can fix that without making things too slow. If I can't, this patch may still be an improvement since it fixes many of the more common cases and breaks a less common one.
Please note that the changesets centric code (and tests) is still in active development on both is behavior (they are probably more bug laying around) and performance. Please refrain from sending patch in this area without coordinating with the people at Octobus doing that work. Thanks.