Skip to content
Snippets Groups Projects
  1. Aug 06, 2014
  2. Apr 13, 2014
  3. Jan 23, 2014
  4. Jan 28, 2013
  5. Nov 22, 2013
  6. Nov 15, 2013
  7. Oct 03, 2013
  8. May 02, 2013
  9. Apr 30, 2013
    • Pierre-Yves David's avatar
      push: make locking of source optional (issue3684) · 3f5e75c22585
      Pierre-Yves David authored
      Having the permission to lock the source repo on push is now optional. When the
      repo cannot be locked, phase are not changed locally. A status message is issue
      when some actual phase movement are skipped:
      
          cannot lock source repo, skipping local public phase update
      
      A debug message with the exact reason of the locking failure is issued in all
      case.
      3f5e75c22585
  10. Sep 14, 2012
  11. Aug 15, 2012
  12. Apr 27, 2012
  13. Apr 24, 2012
    • Pierre-Yves David's avatar
      branchmap: server should not advertise secret changeset in branchmap (Issue3303) · 39d1f83eb05d
      Pierre-Yves David authored
      Discovery now use an overlay above branchmap to prune invisible "secret"
      changeset from branchmap.
      
      To minimise impact on the code during the code freeze, this is achieve by
      recomputing non-secret heads on the fly when any secret changeset exists. This
      is a computation heavy approach similar to the one used for visible heads. But
      few sever should contains secret changeset anyway.  See comment in code for more
      robust approach.
      
      On local repo the wrapper is applied explicitly while the wire-protocol take
      care of wrapping branchmap call in a transparent way. This could be unified by
      the Peter Arrenbrecht and Sune Foldager proposal of a `peer` object.
      
      An inappropriate `(+i heads)` may still appear when pushing new changes on a
      repository with secret changeset. (see Issue3394 for details)
      39d1f83eb05d
  14. Feb 29, 2012
    • Pierre-Yves David's avatar
      bundlerepo: bundle repos should be non-publishing (issue3266) · 40cc20042fb4
      Pierre-Yves David authored
      Bundle repo contains both the bundle content and the content of the repository
      used as a base. This create bugs with phases exchange because the "remote"
      repository claim to contains changeset it does not. The easiest way to fix this
      bug is to ensure a bundle repo as non publishing. This way changeset will be
      seen in the same phase than locally.
      
      This patch does not alter in which phase bundle revision are seen. For now they
      are seen as if an old client had add them on the remote: They inherit their
      phase from parent whatever the parent is. This is to be fixed in a later patch
      40cc20042fb4
  15. Feb 10, 2012
  16. Jan 30, 2012
    • Matt Mackall's avatar
      pull: return 1 when no changes found (BC) · 093b75c7b44b
      Matt Mackall authored
      Currently we have the following return codes if nothing is found:
      
                      commit   incoming    outgoing      pull     push
      intended           1        1           1            1       1
      documented         1        1           1            0       1
      actual             1        1           1            0       1
      
      This makes pull agree with the rest of the table and makes it easy to
      detect "nothing was pulled" in scripts.
      093b75c7b44b
    • Matt Mackall's avatar
      push: return 1 if no changes found (issue3228) · 90f8b8dd0326
      Matt Mackall authored
      Currently we have the following return codes if nothing is found:
      
                      commit   incoming    outgoing      pull     push
      intended           1        1           1            1       1
      documented         1        1           1            0       1
      actual             1        1           1            0       0
      
      This fixes the lower-right entry.
      90f8b8dd0326
  17. Jan 27, 2012
  18. Jan 20, 2012
  19. Jan 13, 2012
  20. Jan 12, 2012
  21. Jan 07, 2012
  22. Jan 06, 2012
  23. Dec 26, 2011
  24. Dec 21, 2011
    • Pierre-Yves David's avatar
      phases: do not exchange secret changesets · cff25e4b37d2
      Pierre-Yves David authored
      Any secret changesets will be excluded from pull and push. Phase data are
      properly synchronized on pull and push if a changeset is seen as secret locally
      but is non-secret remote side.
      
      This patch does not handle the case of a changeset secret on remote but known
      locally.
      cff25e4b37d2
  25. Dec 15, 2011
  26. Oct 26, 2011
  27. Dec 15, 2011
    • Pierre-Yves David's avatar
      phases: add a phases.publish option · 218ec96c45d7
      Pierre-Yves David authored
      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)
      218ec96c45d7
  28. Nov 10, 2011
Loading