Skip to content
Snippets Groups Projects
  1. Dec 15, 2011
    • Pierre-Yves David's avatar
      phases: change publish behavior to only alter behavior when server. · 7fba5a245acc
      Pierre-Yves David authored
      Older publish=True was:
      
        1) Content of Publishing server are seen as public by client.
        2) Any changegroup *added* to a publish=True server is public.
      
      New definition are:
      
        1) Content of Publishing server are seen as public by client.
        2) Any changegroup *pushed* to a publish=True server is public.
      
      See mercurial/phase.py documentation for exact final behavior
      7fba5a245acc
    • Matt Mackall's avatar
      d976b1ef6760
    • Matt Mackall's avatar
      util: clean up function ordering · 4f5a78fa4917
      Matt Mackall authored
      4f5a78fa4917
    • Matt Mackall's avatar
      merge with stable · 5402fd9dd13e
      Matt Mackall authored
      5402fd9dd13e
    • Nikolaus Schueler's avatar
      notify: change behavior of "changegroup" hook · 2a7fa7c641d8
      Nikolaus Schueler authored
      Change the behavior so that the sender (the "From" header in the notification
      mail) in case of the "changegroup" hook is the user that did the first commit
      in the changegroup.  The option is configurable, if you set "notify.fromauthor"
      to "True" in your config, the new behavior is activated.  If you do not set the
      option, the behavior is as before.  The commit adds to an existing test to show
      various aspects of the changed behavior.
      2a7fa7c641d8
    • Na'Tosha Bard's avatar
      largefiles: optimize status when files are specified (issue3144) · 93c77d5b9752
      Na'Tosha Bard authored
      This fixes a performance issue with 'hg status' when files are specified
      on the command-line.  Previously, a large amount of largefiles code was
      executed, even if files were specified on the command-line and those files
      were not largefiles.  This patch fixes the problem by first checking if
      non-largefiles were specified on the command-line and, just letting the
      normal status function handle the case if they were.
      
      On a brand new machine, the execution time for 'hg status filename' on
      a repository with largefiles was:
      
      real    0m0.636s
      user    0m0.512s
      sys     0m0.120s
      
      versus the following (the same repository, with largefiles disabled):
      
      real    0m0.215s
      user    0m0.180s
      sys     0m0.032s
      
      After this patch, the performance of 'hg status filename' on the same
      repository, with largefiles enabled is:
      
      real    0m0.228s
      user    0m0.189s
      sys     0m0.036s
      
      This performance boost is also true when patterns (rather than specific
      files) are specified on the command-line.
      
      In the case where patterns are specified in addition to a file list, we
      just defer to the normal codepath in order to not spend extra time
      expanding the patterns to just risk having to expand them again later.
      93c77d5b9752
  2. Dec 12, 2011
  3. Dec 15, 2011
  4. Oct 26, 2011
  5. 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
  6. Dec 12, 2011
  7. Dec 15, 2011
  8. Dec 10, 2011
  9. Dec 07, 2011
  10. Nov 18, 2011
  11. Nov 10, 2011
  12. Dec 12, 2011
  13. Dec 15, 2011
  14. Dec 14, 2011
  15. Dec 15, 2011
  16. Dec 10, 2011
  17. Dec 09, 2011
  18. Dec 07, 2011
  19. Dec 09, 2011
  20. Dec 08, 2011
  21. Nov 16, 2011
  22. Dec 07, 2011
Loading