view tests/test-branch-tag-confict.t @ 39496:2f9f7889549b

snapshot: introduce an intermediate `_refinedgroups` generator

This method will be used to improve the search for a good snapshot base. To
keep things simpler, we introduce the necessary function before doing any
delta base logic change. The next handful of commits will focus on refactoring
the code to let that new logic land as clearly as possible.

# General Idea

Right now, the search for a good delta base stop whenever we found a good one.
However, when using sparse-revlog, we should probably try a bit harder.

We do significant effort to increase delta re-use by jumping on "unrelated"
delta chains that provide better results. Moving to another chain for a better
result is good, but we have no guarantee we jump at a reasonable point in that
new chain. When we consider over the chains related to the parents, we start
from the higher-level snapshots. This is a way to consider the snapshot closer
to the current revision that has the best chance to produce a small delta. We
do benefit from this walk order when jumping to a better "unrelated" stack.

To counter-balance this, we'll introduce a way to "refine" the result. After a
good delta have been found, we'll keep searching for a better delta, using the
current best one as a starting point.

# Target Setup

The `finddeltainfo` method is responsible for the general search for a good
delta. It requests candidates base from `_candidategroups` and decides which
one are usable.

The `_candidategroups` generator act as a top-level filter, it does not care
about how we pick candidates, it just does basic filtering, excluding
revisions that have been tested already or that are an obvious misfit.

The `_rawgroups` generator is the one with the actual ancestors walking logic,
It does not care about what would do a good delta and what was already tested,
it just issues the initial candidates.

We introduce a new `_refinedgroup` function to bridge the gap between
`_candidategroups` and `_rawgroups`. It delegates the initial iteration logic
and then performing relevant refining of the valid base once found. (This
logic is yet to be added to function)

All these logics are fairly independent and easier to understand when standing
alone, not mixed with each other. It also makes it easy to test and try
different approaches for one of those four layers without affecting the other
ones.

# Technical details

To communicate `finddeltainfo` choice of "current best delta base" to the
`_refinegroup` logic, we plan to use python co-routine feature. The
`_candidategroups` and `_refinegroup` generators will become co-routine. This
will allow `_refinegroup` to detect when a good delta have been found and
triggers various refining steps.

For now, `_candidategroups` will just pass the value down the stack.

After poking at various option, the co-routine appears the best to keep each
layers focus on its duty, without the need to spread implementation details
across layers.

Initial setup.

  $ hg init repo
  $ cd repo
  $ touch thefile
  $ hg ci -A -m 'Initial commit.'
  adding thefile

Create a tag.

  $ hg tag branchortag

Create a branch with the same name as the tag.

  $ hg branch branchortag
  marked working directory as branch branchortag
  (branches are permanent and global, did you want a bookmark?)
  $ hg ci -m 'Create a branch with the same name as a tag.'

This is what we have:

  $ hg log
  changeset:   2:10519b3f489a
  branch:      branchortag
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Create a branch with the same name as a tag.
  
  changeset:   1:2635c45ca99b
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Added tag branchortag for changeset f57387372b5d
  
  changeset:   0:f57387372b5d
  tag:         branchortag
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Initial commit.
  
Update to the tag:

  $ hg up 'tag(branchortag)'
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ hg parents
  changeset:   0:f57387372b5d
  tag:         branchortag
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Initial commit.
  
Updating to the branch:

  $ hg up 'branch(branchortag)'
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg parents
  changeset:   2:10519b3f489a
  branch:      branchortag
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Create a branch with the same name as a tag.
  

  $ cd ..