phases: add a phases.publish option What is a "publishing repository"? ================================== Setting a repository as "publishing" alter its behavior **when used as a server**: all changesets are **seen** as public changesets by clients. So, pushing to a "publishing" repository is the most common way to make changesets public: pushed changesets are seen as public on the remote side and marked as such on local side. Note: the "publishing" property have no effects for local operations. Old repository are publishing ============================= Phase is the first step of a series of features aiming at handling mutable history within mercurial. Old client do not support such feature and are unable to hold phase data. The safest solution is to consider as public any changeset going through an old client. Moreover, most hosting solution will not support phase from the beginning. Having old clients seen as public repositories will not change their usage: public repositories where you push *immutable* public changesets *shared* with others. Why is "publishing" the default? ================================ We discussed above that any changeset from a non-phase aware repository should be seen as public. This means that in the following scenario, X is pulled as public:: ~/A$ old-hg init ~/A$ echo 'babar' > jungle ~/A$ old-hg commit -mA 'X' ~/A$ cd ../B ~/B$ new-hg pull ../A # let's pretend A is served by old-hg ~/B$ new-hg log -r tip summary: X phase: public We want to keep this behavior while creating/serving the A repository with ``new-hg``. Although committing with any ``new-hg`` creates a draft changeset. To stay backward compatible, the pull must see the new commit as public. Non-publishing server will advertise them as draft. Having publishing repository the default is thus necessary to ensure this backward compatibility. This default value can also be expressed with the following sentence: "By default, without any configuration, everything you exchange with the outside is immutable.". This behaviour seems sane. Why allow draft changeset in publishing repository ===================================================== Note: The publish option is aimed at controlling the behavior of *server*. Changeset in any state on a publishing server will **always*** be seen as public by other client. "Passive" repository which are only used as server for pull and push operation are not "affected" by this section. As in the choice for default, the main reason to allow draft changeset in publishing server is backward compatibility. With an old client, the following scenario is valid:: ~/A$ old-hg init ~/A$ echo 'babar' > jungle ~/A$ old-hg commit -mA 'X' ~/A$ old-hg qimport -r . # or any other mutable operation on X If the default is publishing and new commits in such repository are "public" The following operation will be denied as X will be an **immutable** public changeset. However as other clients see X as public, any pull//push (or event pull//pull) will mark X as public in repo A. Allowing enforcement of public changeset only repository through config is probably something to do. This could be done with another "strict" option or a third value config for phase related option (mode=public, publishing(default), mutable)

     1

  $ cat >> $HGRCPATH <<EOF

     2

  > [extensions]

     3

  > graphlog=

     4

  > EOF

     5

  $ alias hgph='hg log --template "{rev} {phase} {desc}\n"'

     6

     7

  $ mkcommit() {

     8

  >    echo "$1" > "$1"

     9

  >    hg add "$1"

    10

  >    hg ci -m "$1"

    11

  > }

    12

    13

  $ hg init alpha

    14

  $ cd alpha

    15

  $ mkcommit a-A

    16

  $ mkcommit a-B

    17

  $ mkcommit a-C

    18

  $ mkcommit a-D

    19

  $ hgph

    20

  3 1 a-D

    21

  2 1 a-C

    22

  1 1 a-B

    23

  0 1 a-A

    24

    25

  $ hg init ../beta

    26

  $ hg push -r 1 ../beta

    27

  pushing to ../beta

    28

  searching for changes

    29

  adding changesets

    30

  adding manifests

    31

  adding file changes

    32

  added 2 changesets with 2 changes to 2 files

    33

  $ hgph

    34

  3 1 a-D

    35

  2 1 a-C

    36

  1 0 a-B

    37

  0 0 a-A

    38

    39

  $ cd ../beta

    40

  $ hgph

    41

  1 0 a-B

    42

  0 0 a-A

    43

  $ hg up -q

    44

  $ mkcommit b-A

    45

  $ hgph

    46

  2 1 b-A

    47

  1 0 a-B

    48

  0 0 a-A

    49

  $ hg pull ../alpha

    50

  pulling from ../alpha

    51

  searching for changes

    52

  adding changesets

    53

  adding manifests

    54

  adding file changes

    55

  added 2 changesets with 2 changes to 2 files (+1 heads)

    56

  (run 'hg heads' to see heads, 'hg merge' to merge)

    57

  $ hgph

    58

  4 0 a-D

    59

  3 0 a-C

    60

  2 1 b-A

    61

  1 0 a-B

    62

  0 0 a-A

    63

    64

pull did not updated ../alpha state.

    65

push from alpha to beta should update phase even if nothing is transfered

    66

    67

  $ cd ../alpha

    68

  $ hgph # not updated by remote pull

    69

  3 1 a-D

    70

  2 1 a-C

    71

  1 0 a-B

    72

  0 0 a-A

    73

  $ hg push ../beta

    74

  pushing to ../beta

    75

  searching for changes

    76

  no changes found

    77

  $ hgph

    78

  3 0 a-D

    79

  2 0 a-C

    80

  1 0 a-B

    81

  0 0 a-A

    82

    83

update must update phase of common changeset too

    84

    85

  $ hg pull ../beta # getting b-A

    86

  pulling from ../beta

    87

  searching for changes

    88

  adding changesets

    89

  adding manifests

    90

  adding file changes

    91

  added 1 changesets with 1 changes to 1 files (+1 heads)

    92

  (run 'hg heads' to see heads, 'hg merge' to merge)

    93

    94

  $ cd ../beta

    95

  $ hgph # not updated by remote pull

    96

  4 0 a-D

    97

  3 0 a-C

    98

  2 1 b-A

    99

  1 0 a-B

   100

  0 0 a-A

   101

  $ hg pull ../alpha

   102

  pulling from ../alpha

   103

  searching for changes

   104

  no changes found

   105

  $ hgph

   106

  4 0 a-D

   107

  3 0 a-C

   108

  2 0 b-A

   109

  1 0 a-B

   110

  0 0 a-A

   111

   112

Publish configuration option

   113

----------------------------

   114

   115

changegroup are added without phase movement

   116

   117

  $ hg bundle -a ../base.bundle

   118

  5 changesets found

   119

  $ cd ..

   120

  $ hg init mu

   121

  $ cd mu

   122

  $ cat > .hg/hgrc << EOF

   123

  > [phases]

   124

  > publish=0

   125

  > EOF

   126

  $ hg unbundle ../base.bundle

   127

  adding changesets

   128

  adding manifests

   129

  adding file changes

   130

  added 5 changesets with 5 changes to 5 files (+1 heads)

   131

  (run 'hg heads' to see heads, 'hg merge' to merge)

   132

  $ hgph

   133

  4 1 a-D

   134

  3 1 a-C

   135

  2 1 b-A

   136

  1 1 a-B

   137

  0 1 a-A

   138