view tests/test-obsolete-checkheads.t @ 39764:e4e881572382

localrepo: iteratively derive local repository type

This commit implements the dynamic local repository type derivation
that was explained in the recent commit
bfeab472e3c0 "localrepo: create new function for instantiating a local
repo object."

Instead of a static localrepository class/type which must be customized
after construction, we now dynamically construct a type by building up
base classes/types to represent specific repository interfaces.

Conceptually, the end state is similar to what was happening when
various extensions would monkeypatch the __class__ of newly-constructed
repo instances. However, the approach is inverted. Instead of making
the instance then customizing it, we do the customization up front
by influencing the behavior of the type then we instantiate that
custom type.

This approach gives us much more flexibility. For example, we can
use completely separate classes for implementing different aspects
of the repository. For example, we could have one class representing
revlog-based file storage and another representing non-revlog based
file storage. When then choose which implementation to use based on
the presence of repo requirements.

A concern with this approach is that it creates a lot more types
and complexity and that complexity adds overhead. Yes, it is true that
this approach will result in more types being created. Yes, this is
more complicated than traditional "instantiate a static type." However,
I believe the alternatives to supporting alternate storage backends
are just as complicated. (Before I arrived at this solution, I had
patches storing factory functions on local repo instances for e.g.
constructing a file storage instance. We ended up having a handful
of these. And this was logically identical to assigning custom
methods. Since we were logically changing the type of the instance,
I figured it would be better to just use specialized types instead
of introducing levels of abstraction at run-time.)

On the performance front, I don't believe that having N base classes
has any significant performance overhead compared to just a single base
class. Intuition says that Python will need to iterate the base classes
to find an attribute. However, CPython caches method lookups: as long as
the __class__ or MRO isn't changing, method attribute lookup should be
constant time after first access. And non-method attributes are stored
in __dict__, of which there is only 1 per object, so the number of
base classes for __dict__ is irrelevant.

Anyway, this commit splits up the monolithic completelocalrepository
interface into sub-interfaces: 1 for file storage and 1 representing
everything else.

We've taught ``makelocalrepository()`` to call a series of factory
functions which will produce types implementing specific interfaces.
It then calls type() to create a new type from the built-up list of
base types.

This commit should be considered a start and not the end state. I
suspect we'll hit a number of problems as we start to implement
alternate storage backends:

* Passing custom arguments to __init__ and setting custom attributes
  on __dict__.
* Customizing the set of interfaces that are needed. e.g. the
  "readonly" intent could translate to not requesting an interface
  providing methods related to writing.
* More ergonomic way for extensions to insert themselves so their
  callbacks aren't unconditionally called.
* Wanting to modify vfs instances, other arguments passed to __init__.

That being said, this code is usable in its current state and I'm
convinced future commits will demonstrate the value in this approach.

Differential Revision: https://phab.mercurial-scm.org/D4642

Check that obsolete properly strip heads
  $ cat >> $HGRCPATH << EOF
  > [phases]
  > # public changeset are not obsolete
  > publish=false
  > [ui]
  > logtemplate='{node|short} ({phase}) {desc|firstline}\n'
  > [experimental]
  > evolution.createmarkers=True
  > EOF
  $ mkcommit() {
  >    echo "$1" > "$1"
  >    hg add "$1"
  >    hg ci -m "add $1"
  > }
  $ getid() {
  >    hg id --debug -ir "desc('$1')"
  > }


  $ hg init remote
  $ cd remote
  $ mkcommit base
  $ hg phase --public .
  $ cd ..
  $ cp -R remote base
  $ hg clone remote local
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd local

New head replaces old head
==========================

setup
(we add the 1 flags to prevent bumped error during the test)

  $ mkcommit old
  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  $ hg up -q '.^'
  $ mkcommit new
  created new head
  $ hg debugobsolete --flags 1 `getid old` `getid new`
  obsoleted 1 changesets
  $ hg log -G --hidden
  @  71e3228bffe1 (draft) add new
  |
  | x  c70b08862e08 (draft) add old
  |/
  o  b4952fcf48cf (public) add base
  
  $ cp -R ../remote ../backup1

old exists remotely as draft. It is obsoleted by new that we now push.
Push should not warn about creating new head

  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)

old head is now public (public local version)
=============================================

setup

  $ rm -fr ../remote
  $ cp -R ../backup1 ../remote
  $ hg -R ../remote phase --public c70b08862e08
  $ hg pull -v
  pulling from $TESTTMP/remote
  searching for changes
  no changes found
  1 local changesets published
  $ hg log -G --hidden
  @  71e3228bffe1 (draft) add new
  |
  | o  c70b08862e08 (public) add old
  |/
  o  b4952fcf48cf (public) add base
  

Abort: old will still be an head because it's public.

  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  abort: push creates new remote head 71e3228bffe1!
  (merge or see 'hg help push' for details about pushing new heads)
  [255]

old head is now public (public remote version)
==============================================

TODO: Not implemented yet.

# setup
#
#   $ rm -fr ../remote
#   $ cp -R ../backup1 ../remote
#   $ hg -R ../remote phase --public c70b08862e08
#   $ hg phase --draft --force c70b08862e08
#   $ hg log -G --hidden
#   @  71e3228bffe1 (draft) add new
#   |
#   | x  c70b08862e08 (draft) add old
#   |/
#   o  b4952fcf48cf (public) add base
#
#
#
# Abort: old will still be an head because it's public.
#
#   $ hg push
#   pushing to $TESTTMP/remote
#   searching for changes
#   abort: push creates new remote head 71e3228bffe1!
#   (merge or see 'hg help push' for details about pushing new heads)
#   [255]

old head is obsolete but replacement is not pushed
==================================================

setup

  $ rm -fr ../remote
  $ cp -R ../backup1 ../remote
  $ hg phase --draft --force '(0::) - 0'
  $ hg up -q '.^'
  $ mkcommit other
  created new head
  $ hg log -G --hidden
  @  d7d41ccbd4de (draft) add other
  |
  | o  71e3228bffe1 (draft) add new
  |/
  | x  c70b08862e08 (draft) add old
  |/
  o  b4952fcf48cf (public) add base
  

old exists remotely as draft. It is obsoleted by new but we don't push new.
Push should abort on new head

  $ hg push -r 'desc("other")'
  pushing to $TESTTMP/remote
  searching for changes
  abort: push creates new remote head d7d41ccbd4de!
  (merge or see 'hg help push' for details about pushing new heads)
  [255]



Both precursors and successors are already know remotely. Descendant adds heads
===============================================================================

setup. (The obsolete marker is known locally only

  $ cd ..
  $ rm -rf local
  $ hg clone remote local
  updating to branch default
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd local
  $ mkcommit old
  old already tracked!
  nothing changed
  [1]
  $ hg up -q '.^'
  $ mkcommit new
  created new head
  $ hg push -f
  pushing to $TESTTMP/remote
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)
  $ mkcommit desc1
  $ hg up -q '.^'
  $ mkcommit desc2
  created new head
  $ hg debugobsolete `getid old` `getid new`
  obsoleted 1 changesets
  $ hg log -G --hidden
  @  5fe37041cc2b (draft) add desc2
  |
  | o  a3ef1d111c5f (draft) add desc1
  |/
  o  71e3228bffe1 (draft) add new
  |
  | x  c70b08862e08 (draft) add old
  |/
  o  b4952fcf48cf (public) add base
  
  $ hg log -G --hidden -R ../remote
  o  71e3228bffe1 (draft) add new
  |
  | o  c70b08862e08 (draft) add old
  |/
  @  b4952fcf48cf (public) add base
  
  $ cp -R ../remote ../backup2

Push should not warn about adding new heads. We create one, but we'll delete
one anyway.

  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 2 changesets with 2 changes to 2 files (+1 heads)


Remote head is unknown but obsoleted by a local changeset
=========================================================

setup

  $ rm -fr ../remote
  $ cp -R ../backup1 ../remote
  $ cd ..
  $ rm -rf local
  $ hg clone remote local -r 0
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  new changesets b4952fcf48cf
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd local
  $ mkcommit new
  $ hg -R ../remote id --debug -r tip
  c70b08862e0838ea6d7c59c85da2f1ed6c8d67da tip
  $ hg  id --debug -r tip
  71e3228bffe1886550777233d6c97bb5a6b2a650 tip
  $ hg debugobsolete c70b08862e0838ea6d7c59c85da2f1ed6c8d67da 71e3228bffe1886550777233d6c97bb5a6b2a650
  $ hg log -G --hidden
  @  71e3228bffe1 (draft) add new
  |
  o  b4952fcf48cf (public) add base
  
  $ hg log -G --hidden -R ../remote
  o  c70b08862e08 (draft) add old
  |
  @  b4952fcf48cf (public) add base
  

We do not have enought data to take the right decision, we should fail

  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  remote has heads on branch 'default' that are not known locally: c70b08862e08
  abort: push creates new remote head 71e3228bffe1!
  (pull and merge or see 'hg help push' for details about pushing new heads)
  [255]

Pulling the missing data makes it work

  $ hg pull
  pulling from $TESTTMP/remote
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)
  (run 'hg heads' to see heads)
  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)

Old head is pruned without parent data and new unrelated head added
===================================================================

setup

  $ cd ..
  $ rm -R remote local
  $ cp -R backup1 remote
  $ hg clone remote local -qr c70b08862e08
  $ cd local
  $ hg up -q '.^'
  $ mkcommit new-unrelated
  created new head
  $ hg debugobsolete `getid old`
  obsoleted 1 changesets
  $ hg log -G --hidden
  @  350a93b716be (draft) add new-unrelated
  |
  | x  c70b08862e08 (draft) add old
  |/
  o  b4952fcf48cf (public) add base
  

  $ hg push
  pushing to $TESTTMP/remote
  searching for changes
  abort: push creates new remote head 350a93b716be!
  (merge or see 'hg help push' for details about pushing new heads)
  [255]