Skip to content
Snippets Groups Projects
Commit 2a985a17 authored by Pierre-Yves David's avatar Pierre-Yves David :octopus:
Browse files

copies: reinstall initial empty files for chained copied

This effectively back out changeset deeb215be337. Changeset deeb215be337 does not
really include a justification for its change and make mes uncomfortable. I have
been thinking about it and they are two options:

- either having empty/full files does not make a difference, and deeb215be337 is
  a gratuitous changes.

- either having empty/full files do make a difference and deeb215be337 silently
  change the test coverage. In such situation if we want the "not empty" case to
  be tested, we should add new cases to cover them

In practice, we know that the "file content did not change, but merge still need
to create a new filenode" case exists (for example if merging result in similar
content but both parent of the file need to be recorded), and that such case are
easy to miss/mess-up in the tests. Having all the file using the same (empty)
content was done on purpose to increase the coverage of such corner case.

As a result I am reinstalling the previous test situation. If we want to
increase the coverage of some case involving content-merge in
test-copies-chain-merge.t, we should add a new, dedicated, cases. For the
current work, it is much more likely to have the corner case broken with the
common case working than the corner case working and the common case broken (cf
the next paragraph). So testing the corner case is more important. I also
suspect that the common case (merge changing the content) is already covered in
`test-copies-chain-merge.t` or elsewhere but I did not had time to investigate
this in details. I am planning to do a extensive pass on the copy tracing
testing to make sure all case we gathered along the way are properly documented
and tested (I am keeping a list). However they are a lot of things to do
regarding copy tracing and my bandwidth is limited. I am currently focussing on
testing and fixing more important (and currently known to be broken) cases.

Doing so has a large impact on the output of the "copy info in changeset extra" variant
added in 5e72827dae1e (2 changesets after deeb215be337). It seems to highlight
various breakage when merge without content change are involved, this is a good
example of why we want to explicitly test theses cases. Because the different
-do- matters a lot.

Fixing the "copy info in changeset extra" is not a priority here. because (1)
this changeset does not break anything, it only highlight that they were always
broken. (2) the only people using "copy info in changeset extra" do not have
merge.

Differential Revision: https://phab.mercurial-scm.org/D9587
parent a27aa754
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment