there is no term 'Changeset, close' in glossary.
'Close changeset' seems to have to be linked not to 'Branch, closed',
but to 'Head, closed branch', because only the latter explains about
"the changeset that marks a head as no longer interesting".
according to configuration example below, and direction of changeset
transference, this paragraph should describe about "changegroup" hook.
[hooks]
# one email for each incoming changeset
incoming.notify = python:hgext.notify.hook
# one email for all incoming changesets
changegroup.notify = python:hgext.notify.hook
# one email for all outgoing changesets
outgoing.notify = python:hgext.notify.hook
according to configuration in "acl.deny" below, group "@hg-denied"
also be denied for all files, so add such description to comment for
configuration.
[acl.deny]
# user6 will not have write access to any file:
** = user6
# Group "hg-denied" will not have write access to any file:
** = @hg-denied
There is no need to use entropy here just to create some content that only will
be used for hashing and ignored.
This avoids a problem where dd from /dev/urandom on solaris generates too short
output.
If the default python encoding was changed from ascii, the attempt to
encode as ascii before lower() could throw a UnicodeEncodeError.
Catch UnicodeError instead to prevent an unhandled exception.
a317664437ee introduced some logic to avoid case-collision detection between
source and destination revisions when it does not make sense: clean or to be
cleaned working directories. Unfortunately, part of it was flawed and the
related test was broken by another bug.
This patch disables cross revision case collision detection for updates without
option or with --check, if the working directory is clean.
Wrapping the status command will only invoke overridestatus() and set
the lfstatus field for the top level repository. Wrapping the status
function is required to set the field on child repositories.
Previously, status -S would report large files in a subrepo as '?'
regardless of their actual states, and was inconsistent with what
status would report from within that subrepo.
on some non "en" locale environments, "hg convert" is aborted, because
"util.parsedate()" fails.
it fails in "memctx.__init__()" called by "putcommit()" of "convert".
in "hg convert", datetimes gotten from source repository
are usually formatted by "util.datestr()" with default format "%a %b
%d %H:%M:%S %Y %1%2".
but on some environments, "%a" and "%b" may cause locale sensitive
string, and such string may cause parse error in "util.parsedate()".
this path uses "%Y-%m-%d %H:%M:%S %1%2" as intermediate representation
format for datetimes, because it consists only of locale insensitive
elements.
datetimes in above format are only used for passing them from
conversion logic to memctx object, so it doesn't have to be formatted
by locale sensitive one.
this patch just avoids locale sensitivity problem of "datestr()" and
"parsedate()" combintion.
svnxml.py parses "svn log --xml" output and prints the attributes shared among
all tested svn versions. This fixes the test with svn 1.7.
Tested with svn 1.6.12 and 1.7.4.
"svn add file" now fails if "file" is already tracked. To filter them we have
to mirror the svn manifest in the sink.
Tested with svn 1.6.12 and 1.7.4.
It seem like docutils 0.8 interpret ':hg:`command`' roles at the beginning of
indented lines in '.. note::' directives as a field that is an invalid argument
to the directive. It fails with 'Error in "note" directive: invalid option
block.' Docutils 0.7 accepted this arguably incorrect markup.
Reflowing the text makes the problem go away. A leading '\ ' could perhaps also
be used to mask the problem.
When rebasing, if a conflict occurs and is resolved in a way the rebased
revision becomes empty, it is not skipped, unlike revisions being emptied
without conflicts.
The reason is:
- File 'x' is merged and resolved, merge.update() marks it as 'm' in the
dirstate.
- rebase.concludenode() calls localrepo.commit(), which calls
localrepo.status() which calls dirstate.status(). 'x' shows up as 'm' and is
unconditionnally added to the modified files list, instead of being checked
again.
- localrepo.commit() detects 'x' as changed an create a new revision where only
the manifest parents and linkrev differ.
Marking 'x' as modified without checking it makes sense for regular merges. But
in rebase case, the merge looks normal but the second parent is usually
discarded. When this happens, 'm' files in dirstate are a bit irrelevant and
should be considered 'n' possibly dirty instead. That is what the current patch
does.
Another approach, maybe more efficient, would be to pass another flag to
merge.update() saying the 'branchmerge' is a bit of a lie and recordupdate()
should call dirstate.normallookup() instead of merge().
It is also tempting to add this logic to dirstate.setparents(), moving from two
to one parent is what invalidates the 'm' markers. But this is a far bigger
change to make.
v2: succumb to the temptation and move the logic in dirstate.setparents(). mpm
suggested trying _filecommit() first but it is called by commitctx() which
knows nothing about the dirstate and comes too late into the game. A second
approach was to rewrite the 'm' state into 'n' on the fly in dirstate.status()
which failed for graft in the following case:
$ hg init repo
$ cd repo
$ echo a > a
$ hg ci -qAm0
$ echo a >> a
$ hg ci -m1
$ hg up 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg mv a b
$ echo c > b
$ hg ci -m2
created new head
$ hg graft 1 --tool internal:local
grafting revision 1
$ hg --config extensions.graphlog= glog --template '{rev} {desc|firstline}\n'
@ 3 1
|
o 2 2
|
| o 1 1
|/
o 0 0
$ hg log -r 3 --debug --patch --git --copies
changeset: 3:19cd7d1417952af13161b94c32e901769104560c
tag: tip
phase: draft
parent: 2:b5c505595c9e9a12d5dd457919c143e05fc16fb8
parent: -1:0000000000000000000000000000000000000000
manifest: 3:3d27ce8d02241aa59b60804805edf103c5c0cda4
user: test
date: Thu Jan 01 00:00:00 1970 +0000
extra: branch=default
extra: source=a03df74c41413a75c0a42997fc36c2de97b26658
description:
1
Here, revision 3 is created because there is a copy record for 'b' in the
dirstate and thus 'b' is considered modified. But this information is discarded
at commit time since 'b' content is unchanged. I do not know if discarding this
information is correct or not, but at this time we cannot represent it anyway.
This patch therefore implements the last solution of moving the logic into
dirstate.setparents(). It does not sound crazy as 'm' files makes no sense with
only one parent. It also makes dirstate.merge() calls .lookupnormal() if there
is one parent, to preserve the invariant.
I am a bit concerned about introducing this kind of stateful behaviour to
existing code which historically treated setparents() as a basic setter without
side-effects. And doing that during the code freeze.
Otherwise, all transplanted revisions are gone and the failing one cannot be
fixed (unless it is the first one).
I do not know what is the expected behaviour with rollback, probably something
pull-like. Non-conflicting cases should work as previously. But something like:
$ hg transplant r1 r2
commiting r1 as c1
failing r2
$ hg transplant --continue
committing r2 as c2
$ hg rollback
would reset the repository to its state before the "transplant --continue"
instead of the whole transplant session. To fix this we might need a way to
open an existing journal file, not sure this is worth the pain.
Git patches are parsed in two phases: 1) extract metadata, 2) parse actual
deltas and merge them with the previous metadata. We do this to avoid
dependency issues like "modify a; copy a to b", where "b" must be copied from
the unmodified "a".
Issue3384 is caused by flaky code I wrote to synchronize the patch metadata
with the emitted hunk:
if (gitpatches and
(gitpatches[-1][0] == afile or gitpatches[-1][1] == bfile)):
gp = gitpatches.pop()[2]
With a patch like:
diff --git a/a b/c
copy from a
copy to c
--- a/a
+++ b/c
@@ -1,1 +1,2 @@
a
+a
@@ -2,1 +2,2 @@
a
+a
diff --git a/a b/a
--- a/a
+++ b/a
@@ -1,1 +1,2 @@
a
+b
the first hunk of the first block is matched with the metadata for the block
"diff --git a/a b/c", then the second hunk of the first block is matched with
the metadata of the second block "diff --git a/a b/a", because of the "or" in
the code paste above. Turning the "or" into an "and" is not enough as we have
to deal with /dev/null cases for each file.
We I remove this broken piece of code:
# copy/rename + modify should modify target, not source
if gp.op in ('COPY', 'DELETE', 'RENAME', 'ADD') or gp.mode:
afile = bfile
because "afile = bfile" set "afile" to stuff like "b/file" instead of "a/file",
and because this only happens for git patches, which afile/bfile are ignored
anyway by applydiff().
v2:
- Avoid a traceback on git metadata desynchronization
Before, import was terminating with a traceback. Now it says:
$ hg import --no-commit ../bad.patch
applying ../bad.patch
abort: could not decode binary patch: bad base85 character at position 66
The fast path was triggered if the argument was not like "type:value", with
type a known pattern type. This is wrong for several reasons:
- path:value is valid for the fast path
- '*' is interpreted as a glob by default and is not valid for fast path
Fast path detection is now done after the pattern is parsed, and the normalized
path is extracted for direct comparison. All this seems a bit complicated, it
is tempting to drop the fast path completely. Also, the hasfile() revset does
something similar (only check .files()), without a fast path. If the fast path
is really that efficient maybe it should be used there too.
Note that:
$ log 'modifies("set:modified()")'
is different from:
$ log 'modifies("*")'
because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences.
Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>
This test gave random failures on slow machines (solaris).
The test was added in 0e28b2998bcf as a test case from issue148. It did however
require manual setup:
The attached script creates such a corruption (you have to add a "import time;
time.spleep(3)" in localrepo.addchangegroup before the changegroup manifest are
written for example.
The test as it is has thus no value as automatic test case.
The necessary sleep could be added by a hook, but test-pending.t already tests
that.
in hgweb help top page, help topics are localized, but abstracts of
commands and extensions are not, although these are already
translated.
it is because localized messages for them should be explicitly looked
up by original ones.
this patch looks localized messages up for each commands/extensions.
The warning is similar to the warning that was shown before hgsubrepo revert
support was added, with the exception that now the subrepo type is shown.
For example, when trying to revert a git subrepo located in "include/mygitsub",
the warning message would be:
include/mygitsub: reverting git subrepos is unsupported
Subversion conversion works by picking trunk and branches heads, computing a
revision graph from them and converting the selected commits. By design we fail
to convert empty revisions so we have to be careful when discovering the
revision graph. In this particular issue, the source svn repository was a
partial mirror made by svnsync. The funny part is svnsync preserves all
revisions including empty ones. Also, we trusted ra.stat(path,
stop).created_rev to give us the latest revision with changes in path history
up to stop. This assumption broke at least when path is '', that is the
repository root, which always returned 'stop' revision despited being empty.
The workaround is to first trust ra.stat() but if the returned revision appear
empty, search the whole path history from stop to r1 until some changes are
found.
The factotum extension used mount and path entries which were too
generic. These have been replaced by mountpoint and executable
(respectively) to match existing conventions.
