Skip to content
Snippets Groups Projects
  1. 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
  2. Dec 12, 2011
  3. Dec 15, 2011
  4. Dec 10, 2011
  5. Dec 07, 2011
  6. Nov 18, 2011
  7. Nov 10, 2011
  8. Dec 15, 2011
  9. Dec 14, 2011
  10. Dec 15, 2011
  11. Dec 10, 2011
  12. Dec 09, 2011
  13. Dec 07, 2011
  14. Dec 09, 2011
  15. Dec 08, 2011
  16. Nov 16, 2011
  17. Dec 07, 2011
  18. Dec 06, 2011
  19. Dec 08, 2011
  20. Dec 07, 2011
  21. Dec 06, 2011
  22. Dec 05, 2011
  23. Dec 04, 2011
    • Patrick Mezard's avatar
      util: fix url.__str__() for windows file URLs · 8f4bad72d8b1
      Patrick Mezard authored
      Before:
      
        >>> str(url('file:///c:/tmp/foo/bar'))
        'file:c%3C/tmp/foo/bar'
      
      After:
      
        >>> str(url('file:///c:/tmp/foo/bar'))
        'file:///c%3C/tmp/foo/bar'
      
      The previous behaviour had no effect on mercurial itself (clone command for
      instance) because we fortunately called .localpath() on the parsed URL.
      hgsubversion was not so lucky and cloning a local subversion repository on
      Windows no longer worked on the default branch (it works on stable because
      de7e2fba4326 defeats the hasdriveletter() test in url class).
      
      I do not know if the %3C is correct or not but svn accepts file:// URLs
      containing it. Mads fixed it in de7e2fba4326, so we can always backport should
      the need arise.
      8f4bad72d8b1
  24. Dec 02, 2011
Loading