- 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)
-
- Dec 12, 2011
-
-
Augie Fackler authored
-
- Dec 15, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Dec 10, 2011
-
-
Fabian Kreutz authored
-
Fabian Kreutz authored
More helptexts have been changed into on id per paragraph. New keywords added. hg example calls changed to :hg:`..` syntax (where changed in EN).
-
- Dec 07, 2011
-
-
Alexander Sauta authored
-
- Nov 18, 2011
-
-
Alexander Sauta authored
-
- Nov 10, 2011
-
-
Andrey Somov authored
-
- Dec 15, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
-
- Dec 14, 2011
-
-
Renato Cunha authored
When a user requested a diff between a revision (r1) that contained a subrepo and another (r2) that did not, mercurial would crash if r1 was specified before r2 but would execute the diff otherwise. This fixes this behavior by skipping the missing subrepo in the diff.
-
- Dec 15, 2011
-
-
Martin Geisler authored
-
- Dec 10, 2011
-
-
Martin Geisler authored
The return statement belongs to the lines above.
-
- Dec 09, 2011
-
-
Ion Savin authored
-
Martin Geisler authored
-
Martin Geisler authored
If a largefile is introduced on the branch that is merged into the working copy, then 'hg status' would abort with an error like: $ hg status abort: .hglf/foo@33fdd332ec64: not found in manifest! The problem was that the largefiles status code only looked in the first parent for the largefile. Largefiles are now always reported as modified if they don't exist in the first parent -- this matches the behavior of localrepo.status for normal files.
-
Martin Geisler authored
Using regular expressions to cut off a (fixed) string prefix is overly complicated and wasteful.
-
Martin Geisler authored
-
- Dec 07, 2011
-
-
Martin Geisler authored
Mercurial 1.7 added the --subrepos flag to status and archive and the largefiles code was still compatible with the old method signatures.
-
- Dec 09, 2011
-
-
Martin Geisler authored
I always found it hard to figure out what the debug code meant without the separators.
-
Thomas Arendsen Hein authored
Extended the list of safe characters introduced in 86fc364ca5f8 to include everything from pipes._safechars, which is only available on Unix platforms. Place "-" at the end of the range to avoid backslash-escape. New characters: @%+=:,
-
- Dec 08, 2011
-
-
Matt Mackall authored
-
kiilerix authored
This restores compatibility with hg-over-ssh servers that don't parse commandlines as sh does but works ok in the most common cases.
-
- Nov 16, 2011
-
-
Kevin Bullock authored
This makes bookmarks.update() and bookmarks.updatecurrentbookmark() return True or False to indicate whether the bookmark was updated or not. This allows callers to e.g. abort if the update failed.
-
- Dec 07, 2011
-
-
Kevin Bullock authored
-
Kevin Bullock authored
Makes the 'nothing to merge' abort messages in commands.py consistent with those in merge.py. Also makes commands.merge() and merge.update() use hints. The tests show the changes.
-
Kevin Bullock authored
-
Na'Tosha Bard authored
-
- Dec 06, 2011
-
-
Olav Reinert authored
-
- Dec 08, 2011
-
-
Matt Mackall authored
-
- Dec 07, 2011
-
-
Matt Mackall authored
-
- Dec 06, 2011
-
-
Matt Mackall authored
-
Christian Ebert authored
-
- Dec 05, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Dec 04, 2011
-
-
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.
-
- Dec 02, 2011
-
-
Wagner Bruna authored
A convert run with a branchmap made with echo default namedbranch > branchmap on Windows fails silently and surprisingly; it actually adds a space after 'namedbranch', so it ends up mapping "default namedbranch" to "". This also affects splicemaps, since the same parser is used for both.
-
Patrick Mezard authored
I modified check-code.py "$?" detection because I thought my use was legit, we cannot test exit status of pipelines commands except for the last one without this. So it now tolerates "[$?" which is unlikely to be added by mistake. Tested on: - OSX + svn 1.7.1 - Linux + svn 1.6.12
-
Patrick Mezard authored
-