- Apr 17, 2014
-
-
Mads Kiilerich authored
-
- Aug 06, 2014
-
-
Matt Mackall authored
-
- Apr 13, 2014
-
-
Mads Kiilerich authored
-
- Jan 23, 2014
-
-
Pierre-Yves David authored
Apparently this issue was fixed along the way (If it ever existed at all…)
-
- Jan 28, 2013
-
-
Pierre-Yves David authored
Now that discovery is working on unfiltered changeset, I had a good occasion to look at that bug again. This let me realise that a trivial node vs rev comparision was the cause of this two years old bugs… Happy second birthday phases!
-
- Nov 22, 2013
-
-
Martin Geisler authored
Since graphlog is in core, we can use 'hg log -G' instead.
-
- Nov 15, 2013
-
-
Matt Mackall authored
This adds a new root hghave to test against. Almost all of these are a subset of unix-permissions, but that is also used for checking exec bit handling.
-
- Oct 03, 2013
-
-
Katsunori FUJIWARA authored
"use push -f to force" in the hint at abortion of "hg push" may cause novice users to execute "push -f" easily without understanding about problems of multiple branch heads in the repository. This patch hides description about "-f" in the hint, and leads into seeing "hg help push" for details about pushing new heads.
-
- May 02, 2013
-
-
Brendan Cully authored
-
- Apr 30, 2013
-
-
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.
-
- Sep 14, 2012
-
-
Patrick Mézard authored
-
- Aug 15, 2012
-
-
kiilerix authored
-
- Apr 27, 2012
-
-
kiilerix authored
-
- Apr 24, 2012
-
-
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)
-
- Feb 29, 2012
-
-
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
-
- Feb 10, 2012
-
-
Matt Mackall authored
This bit a number of people.
-
- Jan 30, 2012
-
-
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.
-
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.
-
- Jan 27, 2012
-
-
kiilerix authored
alias doesn't work in Solaris sh.
-
- Jan 20, 2012
-
-
Pierre-Yves David authored
-
- Jan 13, 2012
-
-
Pierre-Yves David authored
This fix the lack phase movement when a locally secret changeset without added children was pushed to the repository. In such case, this changeset would be present in the bundle source, but not in the ``added`` variable.
-
- Jan 12, 2012
-
-
Pierre-Yves David authored
This apply the redefined stronger semantic of secret. Secret changeset can still leak in various way. Those leak will need to be fixed individualy
-
- Jan 07, 2012
-
-
Pierre-Yves David authored
-
- Jan 06, 2012
-
-
Pierre-Yves David authored
``{phaseidx}`` is providing the phase index as integer. This integer representation is useful when people need to use the fact that phase are ordered. Test keep using the number version for readability purpose.
-
- Dec 26, 2011
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
- Dec 21, 2011
-
-
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.
-
- Dec 15, 2011
-
-
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
-
Pierre-Yves David authored
For now phase sync is tried even if push fails with some know pathological case. The exact behavior is to be discussed and implemented later.
-
Pierre-Yves David authored
Add an extra argument to addchangegroup to all phase code to execute before the lock is released.
-
- Oct 26, 2011
-
-
Pierre-Yves David authored
This will be easier for exchange test.
-
- Dec 15, 2011
-
-
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)
-
- Nov 10, 2011
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-