This is just a short-term workaround for that issue. More work needs to be
done on scmutil.canonpath & friends.
$TMP on Windows is specified to be defined, and it has correct casing, so we
can use that as the default dir for tempfile.mkdtemp on Windows.
This will be used as a step in removing reachable() in a future diff.
Doing it now because bryano is in the process of rewriting ancestors in
C. This depends on bryano's patch to replace *revs with revs in the
declaration of revlog.ancestors.
Accepting a variable number of arguments as the old API did is
deeply ugly, particularly as it means the API can't be extended
with new arguments. Partly as a result, we have at least three
different implementations of the same ancestors algorithm (!?).
Most callers were forced to call ancestors(*somelist), adding to
both inefficiency and ugliness.
It turns out that MSYS does have a chmod.exe, but it has no effect. So, the
inserted "#if unix-permissions" is somewhat redundant, as the test would pass
without it as well: it would simply write the tag cache, despite what the
comment says.
But I'm actually in favor of inserting the #if, as it makes it clearer what's
going on.
This patch changes the function which generates help text about commands and
options to use RST formatting. Tables describing options have been formatted
using RST table markup for some time already, so their appearance does not
change. Command lists, however, change appearance.
To format non-verbose command lists, RST field list markup was chosen, because
it resembles the old format:
<http://docutils.sourceforge.net/docs/user/rst/quickref.html#field-lists>
In the old (hand-coded) format of non-verbose command lists, the left column is
12 characters wide. Our minirst implementation formats field lists with a left
column 14 characters wide, so this patch changes the appearance of help output
correspondingly:
<http://markmail.org/message/krl4cxopsnii7s6z?q=mercurial+reinert+from:%22Olav+Reinert%22&page=2>
The minirst markup most closely resembling the old verbose command lists is
definition lists. But using it would cause a blank line to be inserted between
each command definition, making the output excessively long, and no more
useful than before. To avoid this, I chose to use field lists also for verbose
command help, resulting in output like this example:
add add the specified files on the next commit
annotate, blame
show changeset information by line for each file
clone make a copy of an existing repository
commit, ci commit the specified files or all outstanding changes
diff diff repository (or selected files)
export dump the header and diffs for one or more changesets
forget forget the specified files on the next commit
init create a new repository in the given directory
log, history show revision history of entire repository or files
merge merge working directory with another revision
phase set or show the current phase name
pull pull changes from the specified source
push push changes to the specified destination
qdiff diff of the current patch and subsequent modifications
qinit init a new queue repository (DEPRECATED)
qnew create a new patch
qpop pop the current patch off the stack
qpush push the next patch onto the stack
qrefresh update the current patch
remove, rm remove the specified files on the next commit
serve start stand-alone webserver
status, st show changed files in the working directory
summary, sum summarize working directory state
update, up, checkout, co
update working directory (or switch revisions)
This change is a move towards generating all help text as a list of strings
marked up with RST.
In MSYS, the test fails like this if the hghave exit at the beginning is
removed:
--- C:\Users\adi\hgrepos\hg-main\tests\test-revset.t
+++ C:\Users\adi\hgrepos\hg-main\tests\test-revset.t.err
@@ -58,7 +58,7 @@
$ hg co 3
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg branch /a/b/c/
- marked working directory as branch /a/b/c/
+ marked working directory as branch a:/b/c/
(branches are permanent and global, did you want a bookmark?)
$ hg ci -Aqm"5 bug"
@@ -252,7 +252,7 @@
2 a-b-c-
3 +a+b+c+
4 -a-b-c-
- 5 /a/b/c/
+ 5 a:/b/c/
6 _a_b_c_
7 .a.b.c.
$ log 'children(ancestor(4,5))'
due to the posix path conversion done by MSYS globally, as explained here
http://www.mingw.org/wiki/Posix_path_conversion
The solution is a bit lame, but it is simple and works: don't use strings that
look like '/a/b', in order not to trigger the path magic done by MSYS.
So, if we can agree not to insist on testing branch names starting with '/',
then this relatively simple patch makes the test pass both on Windows with MSYS
and Linux.
If the no-msys exit at the beginning is removed, the test fails on Windows with
MSYS with:
--- C:\Users\adi\hgrepos\hg-main\tests\test-paths.t
+++ C:\Users\adi\hgrepos\hg-main\tests\test-paths.t.err
@@ -24,7 +24,7 @@
expand = $TESTTMP/a/foo/bar (glob)
$ SOMETHING=/foo hg paths
dupe = $TESTTMP/b (glob)
- expand = /foo/bar
+ expand = c:/MinGW/msys/1.0/foo/bar
$ hg paths -q
dupe
expand
caused by http://www.mingw.org/wiki/Posix_path_conversion .
This makes it possible to have conditional sections like:
#if windows
$ echo foo
foo
#else
$ echo bar
bar
#endif
The directives and skipped sections are treated like comments, so don't
interleave them with commands and their output.
The parameters to #if are evaluated while preparing the test by passing them
over to hghave. Requirements can thus be negated with 'no-' prefix, and
multiple requirements must all be true to return true.
For test input lines of *.t files starting with ' >>> ', the code block for
' >>> '
609: if l.startswith(' >>> '): # python inlines
610: after.setdefault(pos, []).append(l)
was (unsurprisingly) executed, but because there was an "if" instead of an
"elif" on the condition "l.startswith(' ... ')", program execution proceeded
to line 636
635: elif l.startswith(' '): # results
636: # queue up a list of expected results
637: expected.setdefault(pos, []).append(l[2:])
due to the fact that if l starts with ' >>> ' it also starts with ' '.
The net effect was that python command lines in *.t files were (surprisingly)
also added to the "expected" dict.
This caused no externally observable bad behavior, as the "expected" dict was
not consulted for these lines.
Allows you to restrict a ssh key to have read-only access to a set of
repos by passing the --read-only flag to hg-ssh.
This is useful in an environment where the number of unix users you
can or are willing to create is limited. In such an environment,
multiple users or applications will share a single unix account. Some
of those applications will likely need read-only access to the
repository. This change makes it possible to grant them such access
without requiring that they use a separate unix account.
The alias expansion code it changed from:
1- Get replacement tree
2- Substitute arguments in the replacement tree
3- Expand the replacement tree again
into:
1- Get the replacement tree
2- Expand the replacement tree
3- Expand the arguments
4- Substitute the expanded arguments in the replacement tree
and fixes cases like:
[revsetalias]
level1($1, $2) = $1 or $2
level2($1, $2) = level1($2, $1)
$ hg log -r "level2(level1(1, 2), 3)"
where the original version incorrectly aborted on infinite expansion
error, because it was confusing the expanded aliases with their
arguments.
The current revset alias expansion code works like:
1- Get the replacement tree
2- Substitute the variables in the replacement tree
3- Expand the replacement tree
It makes it easy to substitute alias arguments because the placeholders
are always replaced before the updated replacement tree is expanded
again. Unfortunately, to fix other alias expansion issues, we need to
reorder the sequence and delay the argument substitution. To solve this,
a new "virtual" construct called _aliasarg() is introduced and injected
when parsing the aliases definitions. Only _aliasarg() will be
substituted in the argument expansion phase instead of all regular
matching string. We also check user inputs do not contain unexpected
_aliasarg() instances to avoid argument injections.
This function augments strip to incrementally update the branchheads cache
rather than recompute it from scratch. This speeds up the performance of strip
and rebase on repos with long history. The performance optimization only
happens if the revisions stripped are all on the same branch and the parents of
the stripped revisions are also on that same branch.
This adds a few test cases, particularly one that reproduces the extra heads
that mpm observed.
Rebase now behaves as if --detach was always passed. Non-merges are
rebased as non-merges, regardless of their parent being an ancestor of
the destination. Merges will usually be rebased as merges unless both of
their parents are ancestors of the destination, or one of their parents
is pruned when rebased.
This only alters the behavior of rebase when using the --source/--rev
options. --detach option is deprecated.
All test changes were carefully validated.
If the string provided to the 'tag' predicate starts with 're:', the rest
of the string will be treated as a regular expression and matched against
all tags in the repository.
There is a slight backwards-compatibility problem for people who actually
have tags that start with 're:'. As a workaround, these tags can be matched
using a 'literal:' prefix.
If no tags match the pattern, an error is raised. This matches the behaviour
of the previous exact-match code.
For divergent renames the following message is printed during merge:
note: possible conflict - file was renamed multiple times to:
newfile
file2
When a file is renamed in one branch and deleted in the other, the file still
exists after a merge. With this change a similar message is printed for mv+rm:
note: possible conflict - file was deleted and renamed to:
newfile
This selects changesets added because of repo conversions. For example
hg log -r "converted()" # all csets created by a convertion
hg log -r "converted(rev)" # the cset converted from rev in the src repo
The converted(rev) form is analogous to remote(id), where the remote repo is
the source of the conversion. This can be useful for cross referencing an old
repository into the current one.
The source revision may be the short changeset hash or the full hash from the
source repository. The local identifier isn't useful. An interesting
ramification of this is if a short revision is specified, it may cause more
than one changeset to be selected. (e.g. converted(6) matches changesets with
a convert_revision field of 6e..e and 67..0)
The convert.hg.saverev option must have been specified when converting the hg
source repository for this to work. The other sources automatically embed the
converted marker.
This is achieved by acting as if the user had given -r<rev> for each head rev
of outgoing changesets on the command line, as well as appropriate
--base <rev>.
The discovery information is computed as normal, and then adjusted as above.
Previously, we were finding the most recent version of a file in a
changeset and comparing it against its first file parent. This was
wrong on three counts:
- it would show a diff in revisions where there was no change to a file
- it would show a diff when only the exec bit changed
- it would potentially compare against a much older changeset, which
could be very expensive if git-style rename detection was enabled
This compares the file in the current context with that context's
parent, which may result in an empty diff when looking at a file not
touched by the current changeset.
Previously, graph data has been encoded for processing done by
JavaScript code run in the browser, employing simple structures
with implicit member positions. This patch modifies the graph
command to also produce data employing a dictionary-based
structure suitable for use with the templating mechanism, thus
permitting other ways of presenting repository graphs using that
mechanism.
In order to test these changes, the raw theme has been modified
to include templates for graph nodes and edges. In a similar
fashion, themes could employ technologies such as SVG that lend
themselves to templating to produce the graph display. This patch
makes use of a much simpler output representation than SVG in
order to maintain clarity.
Extension authors should explicitly declare their supported hg
versions and include a buglink attribute in their extension. In the
event that a traceback occurs, we'll identify the
least-recently-tested extensionas the most likely source of the defect
and suggest the user disable that extension.
Packagers should make every effort to ship hg versions from exact
tags, or with as few modifications as possible so that the versioning
can work appropriately.
I named it --check because it felt like qpush & co were checking *more*
things to ensure local changes could not be lost. But it has been
pointed on the mailing list that --check is already used by update
command with a meaning almost opposite to this one. An alternative
was --keep but qfold and qdelete already have such an option to preserve
patch files and qfold may be a candidate for --check.
- qpush/qpop/qgoto --check becomes --keep-changes.
- mq.check becomes mq.keepchanges.
- The short option -c is dropped as -k may conflict with existing
--keep. The availabilitity of mq.keepchanges should not make this too
painful.
- Fix minor reST mistake in option description.
Add a -B option to remove a bookmark. All revisions are unreachable
from a different head or a different bookmark will be removed too.
This helps with topic branch workflow. You can create a topic branch
and remove it if not needed anymore with hg strip -B topic/xyz.
Destroying history via strip used to invalidate the branchheads cache,
causing it to be regenerated the next time it is read. This is
expensive in large repos. This change converts strip to pass info to
localrepo.destroyed() to enable to it to incrementally update the
cache, improving the performance of strip and other operations that
depend on it (e.g., rebase).
This change also strengthens a bit the integrity checking of the
branchheads cache when it is read, by rejecting the cache if it has
nodes in it that no longer exist.
Bookmarks will behave more like named branches when merge tries to pick
a revision to merge.
Bookmarks now to respect the current bookmarks. Bookmarks will not
accidentally merged with unnamed heads or other bookmarks. However merge
can pick heads with diverging bookmarks and pick those automatically.
We end up with two cases for picking a revision to merge:
(1) In case of an current bookmark, merge can pick a branch head that has a
diverged bookmark
(2) In case of no current bookmark, merge can pick a branch head that does not
have a bookmark.
We allow rebase plus collapse, but not collapse only? I imagine people would
rebase first then collapse once they are sure the rebase is correct and it is
the right time to finish it.
I was reluctant to submit this patch for reasons detailed below, but it
improves rebase --collapse usefulness so much it is worth the ugliness.
The fix is ugly because we should be fixing the collapse code path rather than
the merge. Collapsing by merging changesets repeatedly is inefficient compared
to what commit --amend does: commitctx(), update, strip. The problem with the
latter is, to generate the synthetic changeset, copy records are gathered with
copies.pathcopies(). copies.pathcopies() is still implemented with merging in
mind and discards information like file replaced by the copy of another,
criss-cross copies and so forth. I believe this information should not be lost,
even if we decide not to interpret it fully later, at merge time.
The second issue with improving rebase --collapse is the option should not be
there to begin with. Rebasing and collapsing are orthogonal and a dedicated
command would probably enable a better, simpler ui. We should avoid advertizing
rebase --collapse, but with this fix it becomes the best shipped solution to
collapse changesets.
And for the record, available techniques are:
- revert + commit + strip: lose copies
- mq/qfold: repeated patching() (mostly correct, fragile)
- rebase: repeated merges (mostly correct, fragile)
- collapse: revert + tag rewriting wizardry, lose copies
- histedit: repeated patching() (mostly correct, fragile)
- amend: copies.pathcopies() + commitctx() + update + strip
Since f7e538c3b7ba, if a chunk starts with "@@ -0,1", oldstart turns into
a negative value. Because diffhelpers.testhunk() doesn't expect negative bstart,
it bypasses "alen > blen - bstart" condition and segfaults at
"PyList_GET_ITEM(b, i + bstart)".
When:
[mq]
check = True
is set, qpush, qpop and qgoto behave as if -c/--check were passed. If
incompatible options like -f/--force or --exact are set, this setting is
ignored.
This setting enables what many users expect mq default behaviour to be.
qpush help says the following about --force:
1- When -f/--force is applied, all local changes in patched files will
be lost.
2- Apply on top of local changes
In practice, qpush --force will attempt to apply the patch on top of
local changes, and on success will merge them in the pushed patch. On
failure, patched files will contain a mix of local changes (where the
patch could not apply) and a mix of patch changes (were it applied). So,
local changes are less lost than entangled with a mass of other changes.
This patch makes qpush --force backup all locally modified files touched
by the next patch being applied. When multiple patches are being pushed,
this logic is repeated for each patch. Note that modified but
successfully patched files are preserved as well.
Commands working without a repository, like "init", are listed in
commands.norepo. Commands optionally using a repository, like "showconfig", are
listed in commands.optionalrepo. Command aliases were inheriting the former but
not the latter.
brendan mentioned on IRC that b64decode raises a TypeError too, but while the
previous exception type may be better in general, it is much easier to make it
behave like the related C code and changes nothing for mercurial itself.
Calling strip() will eventually trigger localrepo.destroyed() which will
invalidate _parseroots. It will call filterunknown() upon reload.
Changes to test-keyword.t are related to commit --debug running after
either qpop or rollback.
The behaviour is correct but for bad reasons: the repo.set() call in
phase command fails for '-1'. It should be rejected explicitely by phase
boundary commands, sadly this is hard to do because phase changes are
not applied atomically.
largefiles status implementation attemps to rewrite the input match objects to
match the "standins" as well as the regular files. When fixing the directories
listed in match.files(), if there was related standin entry, it was kept and
the original path discarded. But directories can appear both as regular and
standin entries.
Note that aborting in subrepo.state() prevents "repairing" commands like revert
to be issued. The user will have to edit the .hgsubstate manually (but he
probably had already otherwise this would not be failing). The same behaviour
already happens with invalid .hgsub entries.
Let R be a repo served by an hg daemon on a machine with an empty largefiles
cache. Pushing a largefiles repo to R will result in a no-such-file-or-directory
OSError because putlfile will attempt to create a temporary file in
R/.hg/largefiles, which does not yet exist.
This patch also adds a regression test for this scenario.
This is essentially a copy of largefile's override of archive() in the
archival class, adapted for overriding hgsubrepo's archive(). That
means decoding isn't taken into consideration, nor is .hg_archival.txt
generated (the same goes for regular subrepos). Unlike subrepos, but
consistent with largefile's handling of the top repo, ui.progress() is
*not* called. This should probably be refactored at some point, but
at least this generates the archives properly for now. Previously,
the standins were ignored and the largefiles were archived only for
the top level repo.
Long term, it would probably be most desirable to figure out how to
tweak archival's archive() if necessary such that largefiles doesn't
need to override it completely just to special case the translating of
standins to the real files. Largefiles will already return a context
with the true largefiles instead of the standins if lfilesrepo's
lfstatus is True- perhaps this can be leveraged?
The initial version was to take the "Revision" field from svn info. It works
but produces false positive when parent paths are being moved or unrelated
changes are being committed, causing it to change while the svn checkout itself
remains the same. To avoid spurious commit, we took "Revision" and "Last
Changed Rev" for general comparison and kept the latter to answer "what is your
revision?" question. This is better but fails when the subrepo path exists at
"Revision" but not at "Last Changed Rev". This patch adds a check for this, and
returns "Revision" if the path does not exist. We try to avoid doing this as
much as possible at it implies an extra, *remote* call.
Messing with the dirstate before the intermediate commit seems error prone.
Instead, commit and recompute the copies with copies.pathcopies(), then use
that with commitctx().
Since copies.pathcopies() does not support file replacement very well, the
whole .renamed() condition in samefile() is removed and the "file replacement
caused by differing copy source" effect is discarded.
Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>
The weirdness is --amend let you replace one file with another with same data
and flags if the new file copy record differ from the one in the parent
revision. In theory, there is no problem with this kind of thing, subversion
supports it, but here we see log and status disagree. The reason is log reads
the copy record from the filelog, while status calls copies.pathcopies() which
eventually invokes some expensiveness argument to discard this case (copies.py,
_forwardcopies(), line 132). Since the next patch will side with pathcopies(),
I prefer to call this behaviour a bug.
The fix introduced in 3509b9cf8f86 was only partially successful. It is correct
to turn dirstate 'm' merge records into normal/dirty ones but copy records are
lost in the process. To adjust them as well, we need to look in the first
parent manifest to know which files were added and preserve only related
records. But the dirstate does not have access to changesets, the logic has to
moved at another level, in localrepo.
The original issue was something like:
$ hg init repo
$ cd repo
$ mkdir D
$ echo a > D/a
$ hg ci -Am adda
adding D/a
$ mv D temp
$ mv temp d
$ echo b > d/b
$ hg add d/b
adding D/b
$ hg ci -m addb
$ hg mv d/b d/c
moving D/b to d/c
$ hg st
A d/c
R D/b
Here we expected:
A D/c
R D/b
the logic being we try to preserve case of path components already known in the
dirstate. This is fixed by the current patch.
Note the following stories are not still not supported:
Changing directory case
$ hg mv D d
moving D/a to D/D/a
moving D/b to D/D/b
$ hg st
A D/D/a
A D/D/b
R D/a
R D/b
or:
$ hg mv D/* d
D/a: not overwriting - file exists
D/b: not overwriting - file exists
And if they were, there are probably similar issues with diffing/patching.
Here is a script illustrating the previous behaviour:
The merge brings a new file 'b' from remote
$ hg merge 1 --debug
searching for copies back to rev 1
unmatched files in other:
b
resolving manifests
overwrite: False, partial: False
ancestor: 07f494440405, local: 540395c44225+, remote: 102a90ea7b4a
b: remote created -> g
updating: b 1/1 files (100.00%)
getting b
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Delete but do not remove b
$ rm b
$ hg st
! b
The commit succeeds
$ hg commit -m merge
$ hg parents --template "{rev} {desc|firstline} files: {files}\n"
3 merge files:
$ hg st
! b
b changes were ignored, but even b existence was ignored
$ hg manifest
a
This happens because localrepo.commitctx() checks the input ctx.files(), which
is empty for workingctx.files() only returns added, modified or removed
entries, and bypass files/manifest updates completely. So the committed
revision manifest is the same as its first parent one, not containing the 'b'
file.
This patch forces the commit to abort in presence of a merge and missing files.
test-merge4.t is modified accordingly as it was introduced to check hg was not
just terminating with a traceback (5cc0d3ba11f9).
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)
The previous code was rebasing an applied series like:
patch1 +guarded
patch2
patch3 +guarded
patch4
patch5 +guarded
into:
patch2
patch4
patch1 +guarded
patch3 +guarded
patch5 +guarded
Reported by Lars Westerhoff <lars.westerhoff@newtec.eu>
Also rename mq.series_dirty into mq.seriesdirty, missed by 9bcf8cbb1bcf, and
without effect since mq.qimport() was setting it already.
Previous code was printing a traceback because it expected some error output
from svn. But sometimes our definition of "changed" differs with the subversion
one. For instance, subversion ignores missing files when committing. And when
there are only missing files, svn commit will be a successful no-op with no
output. Still, we should stick to our definition including missing files in
changes as doing otherwise could cause surprising behaviour for the user.
The only place where an trailing CR could be meaningful is in the "diff --git"
line as part of a filename, and existing code already rule out this
possibility. Extend the CR/LF filtering to the whole binary hunk.
$ hg import --no-commit ../mercurial_1915035238540490516.patch
applying ../mercurial_1915035238540490516.patch
abort: could not extract binary data
Becomes:
abort: could not extract "binary2" binary data
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>
Summary and commit use dirty() to check the status of a subrepository,
so this overrides dirty() in the subrepo in the same manner as
status() to check the large files instead of their standins.
Previously, if only a large file was changed in a subrepo, summary in
the top level repo would not report the subrepo was dirty and commit
-S would report nothing changed. If any type of file was changed in
the top repo and only a large file in the subrepo, commit -S would not
commit the changes to the subrepo.
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.
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.
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
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
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.
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.
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.
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 --amend flag can be used to amend the parent of the working directory
with a new commit that contains the changes in the parent in addition to
those currently reported by "hg status", if there are any. The old commit
is stored in a backup bundle in ".hg/strip-backup"(see "hg help bundle"
and "hg help unbundle" on how to restore it).
Message, user and date are taken from the amended commit unless specified.
When a message isn't specified on the command line, the editor will open
with the message of the amended commit.
It is not possible to amend public changesets (see "hg help phases") or
changesets that have children.
Behind the scenes, first commit the update (if there is one) as a regular
child of the current parent. Then create a new commit on the parent's
parent with the updated contents. Then change the working copy parent
to this new combined changeset. Finally, strip the amended commit and
update commit created in the beginning.
An alternative (cleaner?) approach of doing this is suggested here:
http://selenic.com/pipermail/mercurial-devel/2012-March/038540.html
It is currently not possible to amend merge commits or recursively,
this can be added at a later time.
- _svncommand() in files() returns a tuple since 1ca3bbcf0c2a not a string.
- _svncommand() in filedata() returns a tuple not a string.
- "svn list" returns files but also directories.
- "svn list" is not recursive by default.
I have no idea what happens to svn:externals possibly embedded in the svn
subrepository.
if the file in target context causes case-folding collision against
one in working context, current implementation aborts merging with it,
even thouhg collding one (in target) is the file renamed from collided
one (in working).
this patch uses file copy information to know whether colliding file
is renamed from collided one or not: if so, collision between them is
ignored.
this patch also avoids collision detection between current context and
target context, if working context is clean (with --check/-c) or will
be clean (with --clean/-C).
Here is how export and mq write the "Parent" header:
mq: # Parent XXXXX
export: # Parent XXXXX
then import expects exactly 2 spaces while mq tolerates one or more. So "hg
import --exact" truncates mq generated patches header by one character and
fails. This patch aligns import "Parent" header parsing on mq one. I do not
expect spaces in parent references anytime soon.
Reported by Stefan Ring <stefanrin@gmail.com>
This adds a couple of tests for the revset "matching" keyword:
1. Test that the 2nd parameter is optional
2. Test that all the 1st argument can be a revset and that all the supported
fields of the 2nd argument work.
test-hup hangs on AIX. Under ksh89 on AIX (the default shell),
echo Hello; while [ ! -s not-there ]; do true; done
produces no output while the loop executes. Replacing 'true' with 'sleep 0'
fixes, as does using a less broken shell. ksh93 is fine.
Update check-code.py to look for this, and make same change in test-serve.t.
In fact test-serve works fine, probably because of additional commands between
echo and the loop, but that's a subtlety not easy to test for.
diff ---/+++ should end filenames with a TAB when they contain spaces. Current
code failed to do so when only the +++ file had spaces. This only happened with
git renames from a name without space to one with space.
This fixes "hg qimport -r null". Previous versions used to:
- Traceback because null revision mutability was not defined
- Add an empty -1.diff patch to the series
The error message:
abort: revision -1 is not mutable
is symptomatic of a deeper problem in phase command revision handling. It could
be fixed easily in the command itself but I feel a better fix must be done in
phase API which raises the issue of phase updates atomicity: aborting in
phases.advanceboundary/retractboundary requires a better rollback behaviour to
avoid partial changes.
