Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:19:57 -0800] rev 24022
trydiff: make 'revs' ignored if opts.git is set
Instead of setting revs=None to prevent the call to diffline() when
opts.git is set, explicitly do not call the function in the git case.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:58:51 -0800] rev 24021
trydiff: remove unused argument to diffline()
Now that diffline no longer knows about copies/renames, it only needs
one argument for the path.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:58:06 -0800] rev 24020
trydiff: move git-header code out of diffline function
This collects more of the code for writing git headers in a single
place and makes diffline() close on a few variables less.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 27 Jan 2015 09:22:59 -0500] rev 24019
_fm1readmarkers: generate list in C
This moves perfloadmarkers from
! result: 63866
! wall 0.239217 comb 0.250000 user 0.240000 sys 0.010000 (best of 42)
to
! result: 63866
! wall 0.218795 comb 0.210000 user 0.210000 sys 0.000000 (best of 46)
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 13:38:07 -0500] rev 24018
obsolete: use parsers.fm1readmarker if it exists for a ~38% perf win
This moves perfloadmarkers on my linux workstation (63494 markers from
mpm, crew, and myself) performance from
! wall 0.357657 comb 0.360000 user 0.350000 sys 0.010000 (best of 28)
to
! wall 0.222345 comb 0.220000 user 0.210000 sys 0.010000 (best of 41)
which is a pretty good improvement.
On my BSD machine, which is ancient and slow, before:
! wall 3.584964 comb 3.578125 user 3.539062 sys 0.039062 (best of 3)
after:
! wall 2.267974 comb 2.265625 user 2.195312 sys 0.070312 (best of 5)
I feel like we could do better by moving the whole generator function
into C, but I didn't want to tackle that right away.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:11:25 -0500] rev 24017
parsers: add fm1readmarker
This lets us do most of the interesting work of parsing obsolete
markers in C, which should provide significant time savings.
Thanks to Martin von Zweigbergk for some cleanups on this code.
Augie Fackler <augie@google.com> [Tue, 03 Feb 2015 13:17:21 -0500] rev 24016
util: add getbefloat64
As far as I can tell, this is wrong. double's format isn't strictly
specified in the C standard, but the wikipedia article implies that
platforms implementing optional Annex F "IEC 60559 floating-point
arithmetic" will work correctly.
My local C experts believe doing *((double *) &t) is a strict aliasing
violation, and that using a union is also one. Doing memcpy appears to
be the least-undefined behavior possible.
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 14:09:57 -0500] rev 24015
util: add getbe{u,}int16 utility methods
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 09:38:22 -0500] rev 24014
obsolete: make optional offset parameter to fm*readmarkers required
It was always passed by the only callsite, so just make it required.
Augie Fackler <augie@google.com> [Mon, 02 Feb 2015 14:26:47 -0500] rev 24013
log: fix json-formatted output when file copies are listed (issue4523)
Matt Mackall <mpm@selenic.com> [Tue, 03 Feb 2015 17:54:01 -0600] rev 24012
merge with stable
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 17:24:12 -0800] rev 24011
copy: move _forwardcopies file logic to a function
Moves the _forwardcopies missingfiles logic to a separate function so that other
extensions which need to prefetch information about the files being
processed have a hook point.
This saves extensions from having to recompute this information themselves, and
thus saves several seconds off of various commands (like rebase).
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 17:23:18 -0800] rev 24010
copy: move mergecopies file logic to a function
Moves the mergecopies nonoverlap logic to a separate function so that other
extensions which may need to prefetch information about the files being
processed have a hook point.
This saves extensions from having to recompute this information themselves, and
thus saves several seconds off of various commands (like rebase).
Durham Goode <durham@fb.com> [Mon, 02 Feb 2015 16:19:35 -0800] rev 24009
histedit: allow configuring default behavior
Adds a configuration setting for allowing users to specify the default behavior
of 'hg histedit' without arguments. This saves users from having to manually
figure out the bottom commit or a complicated revset. My current revset of
choice is "only(.) & draft() - ::merge()"
The commits that histedit can work with is usually quite limited, so if this
feature ends up working well, we may want to consider making "only(.) & draft()
- ::merge()" the default behavior for everyone.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 03 Feb 2015 21:56:29 +0900] rev 24008
revset: get revision number of each node from target namespaces
Before this patch, revset predicate "named()" uses each nodes gotten
from target namespaces directly.
This causes problems below:
- combination of other predicates doesn't work correctly, because
they assume that revisions are listed up in number
- "hg log" doesn't show any revisions for "named()" result, because:
- "changeset_printer" stores formatted output for each revisions
into dict with revision number (= ctx.rev()) as a key of them
- "changeset_printer.flush(rev)" writes stored output for
the specified revision, but
- "commands.log" invokes it with the node, gotten from "named()"
- "hg debugrevspec" shows nodes (= may be binary) directly
Difference between revset predicate "tag()" and "named('tags')" in
tests is fixed in subsequent patch.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Feb 2015 14:05:15 -0500] rev 24007
largefiles: update _subdirlfs() comment
http://www.selenic.com/pipermail/mercurial-devel/2015-February/065958.html
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Jan 2015 00:13:29 -0500] rev 24006
largefiles: use the core file copy logic to validate the destination path
The destination is validated by pathutil.canonpath() for illegal components, and
that it is in the repository. The logic for creating the standin directory tree
was calling this before cmdutil.copy(), but without the destination file name
component. The cmdutil.copy() logic also calls pathutil.canonpath(), but with
the file name component. By always calling the core logic first, the error
message is always consistent. Specifically, the old behavior for these tests
was to say '.hg' contains an illegal component, and '..' is not under root.
A user wasn't likely to notice the discrepancy, but this eliminates a needless
difference when running the test suite with --config extensions.largefiles=.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:40:59 -0800] rev 24005
trydiff: inline indexmeta()
The function is trivial and is only called in one place.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 23 Jan 2015 14:09:49 -0800] rev 24004
parsers: rewrite index_ancestors() in terms of index_commonancestorsheads()
The first 80% of index_ancestors() is identical to
index_commonancestorsheads(), so just call that function instead.
Mike Edgar <adgar@google.com> [Thu, 22 Jan 2015 11:09:34 -0500] rev 24003
filelog: remove unused _file method
Mateusz Kwapich <mitrandir@fb.com> [Mon, 26 Jan 2015 15:18:07 -0800] rev 24002
histedit: store full node hash in rules
Previously histedit only stored the short version of the rule nodes in the
state. This meant that later we couldn't resolve a rule node to its full
form if the commit had been deleted from the repo.
Let's store the full form from the beginning.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:49:08 -0800] rev 24001
trydiff: order header-writing code in same order as output
Instead of inserting a line before the others header lines, move the
code that writes that line before the code that writes the other
lines.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:53:37 -0800] rev 24000
trydiff: inline sole addmodehdr() call
Now that there is only a single call to addmodehdr() left, and there
is other similar code (for new/deleted files) around that call site,
let's inline the function there. That also makes it clearer under what
circumstances the header is actually written (when modes differ).
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:46:03 -0800] rev 23999
trydiff: join filename with prefix only once
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jan 2015 17:00:54 -0800] rev 23998
trydiff: collect header-writing in one place
This is the first step towards simplifying the big loop in
trydiff(). This will make both the header code and the non-header code
clearer, and it prepares for further simplification of the many nested
if-statements in the body of the loop.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 10:57:13 -0800] rev 23997
trydiff: make variable names more consistent
Use '1' and '2' as suffix for names just like in the parameters
'ctx[12]':
to,tn -> content1,content2
a,b -> f1, f2
omode,mode -> mode1,mode2
omode,nmode -> mode1,mode2
onode,nnode -> node1,node2
oflag,nflag -> flag1,flag2
oindex,nindex -> index1,index2
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 17:01:58 -0800] rev 23996
trydiff: check only if added file is a copy target, not source
When creating a diff with copy/rename enabled, we consider added files
and check if they are either copy sources or targets. However, an
added file should never be a copy source. The test suite seems to
agree with this: all tests pass if we raise an exception when an added
file is a copy source. So, let's simplify the code by dropping the
conditions that are never true.
For those interested in the historical reasons:
Before commit d1f209bb9564 (patch: separate reverse copy data
(issue1959), 2010-02-11), 'copy' seems to have been a bidirectional
map. Then that commit split it up into two unidirectional maps and
duplicated the logic to look in both maps. It was still needed at that
point to look in both maps, as the copy detection was poor and could
sometimes be reported in reverse.
A little later came 91eb4512edd0 (copies: rewrite copy detection for
non-merge users, 2012-01-04). That commit fixed the copy detection to
be backwards when it should, and made the hacks in trydiff
unnecessary.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Jan 2015 21:12:35 -0800] rev 23995
trydiff: remove unused variable 'modifiedset'
We started updating 'modifiedset' in a9853fc172d2 (trydiff: simplify
checking for additions, 2014-12-23) but in the same commit, we removed
the last use of the variable. Clean it up.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Feb 2015 23:07:04 +0900] rev 23994
revset: replace parsing alias definition by _parsealiasdefn to parse strictly
Before this patch, referring alias arguments is parsed by string base
operation "str.replace".
This causes problems below (see the previous patch introducing
"_parsealiasdefn" for detail)
- the shorter name argument breaks referring the longer name
- argument names in the quoted string are broken
This patch replaces parsing alias definition by "_parsealiasdefn" to
parse strictly.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Feb 2015 23:07:04 +0900] rev 23993
revset: introduce _parsealiasdefn to parse alias definitions strictly
This patch introduces "_parsealiasdefn" to parse alias definitions
strictly. For example, it can avoid problems below, which current
implementation can't.
- the shorter name argument breaks referring the longer name one in
the definition, if the former is completely prefix of the latter
for example, the alias definition "foo($1, $10) = $1 or $10" is
parsed as "_aliasarg('$1') or _aliasarg('$1')0" and causes parse
error, because tail "0" of "_aliasarg('$1')0" is invalid.
- argument names in the quoted string are broken
for example, the definition "foo($1) = $1 or desc('$1')" is parsed
as "_aliasarg('$1') or desc('_aliasarg(\'$1\')')" and causes
unexpected description matching against not '$1' but '_aliasarg(\'$1\')'.
To decrease complication of patch, current implementation for alias
definitions is replaced by "_parsealiasdefn" in the subsequent
patch. This patch just introduces it.
This patch defines "_parsealiasdefn" not as a method of "revsetalias"
class but as a one of "revset" module, because of ease of testing by
doctest.
Yuya Nishihara <yuya@tcha.org> [Mon, 02 Feb 2015 22:28:52 +0900] rev 23992
hgweb: use revset.spanset where appropriate
It is remainder of 9ad6dae67845 where spanset was introduced.
Mathias De Maré <mathias.demare@gmail.com> [Sun, 01 Feb 2015 14:09:31 +0100] rev 23991
subrepo: add 'cat' support for git subrepos
V2: use 'self._ctx.node()' instead of 'rev' in makefileobj.
As Matt Harbison mentioned, using 'rev' does not make sense,
since we'd be passing a git revision to the top-level
Mercurial repository.
Matt Mackall <mpm@selenic.com> [Mon, 02 Feb 2015 12:50:48 -0600] rev 23990
merge with stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 20:21:02 -0600] rev 23989
Added signature for changeset fbdd5195528f
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 20:20:51 -0600] rev 23988
Added tag 3.3 for changeset fbdd5195528f
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 18:47:04 -0600] rev 23987
merge with i18n
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 08:24:08 +0900] rev 23986
i18n-ja: synchronized with 9a391d720cf9
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 29 Jan 2015 10:13:18 -0200] rev 23985
i18n-pt_BR: synchronized with 448bb32b8ee6
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:33:45 -0600] rev 23984
filectx: use _descendantrev in parents()
This lets us be lazy about linkrev adjustments when tracing history.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:26:35 -0600] rev 23983
filectx: if we have a _descendantrev, use it to adjust linkrev
This lets us use _adjustlinkrev lazily.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:25:12 -0600] rev 23982
copies: use linkrev for file tracing limit
This lets us lazily evaluate _adjustlinkrev.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:23:07 -0600] rev 23981
filectx: use linkrev to sort ancestors
We're going to make rev() lazily do _adjustlinkrevs, and we don't want
that to happen when we're quickly tracing through file ancestry
without caring about revs (as we do when finding copies).
This takes us back to pre-linkrev-correction behavior, but shouldn't
regress us relative to the last stable release.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 16:02:28 +0000] rev 23980
_adjustlinkrev: reuse ancestors set during rename detection (issue4514)
The new linkrev adjustement mechanism makes rename detection very slow, because
each file rewalks the ancestor dag. To mitigate the issue in Mercurial 3.3, we
introduce a simplistic way to share the ancestors computation for the linkrev
validation phase.
We can reuse the ancestors in that case because we do not care about
sub-branching in the ancestors graph.
The cached set will be use to check if the linkrev is valid in the search
context. This is the vast majority of the ancestors usage during copies search
since the uncached one will only be used when linkrev is invalid, which is
hopefully rare.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 14:39:03 +0000] rev 23979
filectx: move _adjustlinkrev to a method
We are going to introduce some wider caching mechanisms during linkrev
adjustment. As there is no specific reason to not be a method and some
reasons to be a method, let's make it a method.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 31 Jan 2015 01:00:50 +0900] rev 23978
revset: raise RepoLookupError to make present() predicate continue the query
Before this patch, "bookmark()", "named()" and "tag()" predicates
raise "Abort", when the specified pattern doesn't match against
existing ones.
This prevents "present()" predicate from continuing the query, because
it only catches "RepoLookupError".
This patch raises "RepoLookupError" instead of "Abort", to make
"present()" predicate continue the query, even if "bookmark()",
"named()" or "tag()" in the sub-query of it are aborted.
This patch doesn't contain raising "RepoLookupError" for "re:" pattern
in "tag()", because "tag()" treats it differently from others. Actions
of each predicates at failure of pattern matching can be summarized as
below:
predicate "literal:" "re:"
---------- ----------- ------------
bookmark abort abort
named abort abort
tag abort continue (*1)
branch abort continue (*2)
---------- ----------- ------------
"tag()" may have to abort in the (*1) case for similarity, but this
change may break backward compatibility of existing revset queries. It
seems to have to be changed on "default" branch (with "BC" ?).
On the other hand, (*2) seems to be reasonable, even though it breaks
similarity, because "branch()" in this case doesn't check exact
existence of branches, but does pick up revisions of which branch
matches against the pattern.
This patch also adds tests for "branch()" to clarify behavior around
"present()" of similar predicates, even though this patch doesn't
change "branch()".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 09:36:47 +0900] rev 23977
templatekw: re-add showtags() to list tags keyword up in online help
Changeset d69a7fc68ad5 removed "showtags()" definition for "tags"
template keyword from "templatekw.py", because "namespaces" puts a
helper function for it into template keyword map automatically. This
works correctly from the point of view of templating functionality.
But on the other hand, it removed "tags" template keyword from "hg
help templates" unexpectedly, because online help text is built before
"namespaces" puts a helper function for "tags" into template keyword
map.
This patch is a kind of backing d69a7fc68ad5 out, but this implements
"showtags()" with newly introduced "shownames()" instead of originally
used "showlist()".
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Jan 2015 20:44:11 -0500] rev 23976
largefiles: don't interfere with logging normal files
The previous code was adding standin files to the matcher's file list when
neither the standin file nor the original existed in the context. Somehow, this
was confusing the logging code into behaving differently from when the extension
wasn't loaded.
It seems that this was an attempt to support naming a directory that only
contains largefiles, as a test fails if the else clause is dropped entirely.
Therefore, only append the "standin" if it is a directory. This was found by
running the test suite with --config extensions.largefiles=.
The first added test used to log an additional cset that wasn't logged normally.
The only relation it had to file 'a' is that 'a' was the source of a move, but
it isn't clear why having '.hglf/a' in the list causes this change:
@@ -47,6 +47,11 @@
Make sure largefiles doesn't interfere with logging a regular file
$ hg log a --config extensions.largefiles=
+ changeset: 3:2ca5ba701980
+ user: test
+ date: Thu Jan 01 00:00:04 1970 +0000
+ summary: d
+
changeset: 0:9161b9aeaf16
user: test
date: Thu Jan 01 00:00:01 1970 +0000
The second added test used to complain about a file not being in the parent
revision:
@@ -1638,10 +1643,8 @@
Ensure that largefiles doesn't intefere with following a normal file
$ hg --config extensions.largefiles= log -f d -T '{desc}' -G
- @ c
- |
- o a
-
+ abort: cannot follow file not in parent revision: ".hglf/d"
+ [255]
$ hg log -f d/a -T '{desc}' -G
@ c
|
Note that there is still something fishy with the largefiles code, because when
using a glob pattern like this:
$ hg log 'glob:sub/*'
the pattern list would contain '.hglf/glob:sub/*'. None of the tests show this
(this test lives in test-largefiles.t at 1349), it was just something that I
noticed when the code was loaded up with print statements.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:11:02 +0000] rev 23975
discovery: properly exclude locally known but filtered heads
The conditional was a bit too narrow and produced buggy result when a node was
present in both common and heads (because it pleased the discovery) and it was
locally known but filtered.
This resulted in buggy getbundle request and server side crash.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:40:30 +0000] rev 23974
test: make test-extdiff resilient to /usr/bin/echo
My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 18:49:33 +0000] rev 23973
obsstore: make the invalid markers check wrap-able
Some evolve user ignored the invalid markers for about two years and still have
some of them in some repository. This lead to plain abort whenever mercurial try
to open such repo. We need reinstall some way to clean this up in the evolve
extension. For this purpose, we need the checker code wrap-able independently.
This is scheduled for stable as this issue is blocking some evolve user.
Mads Kiilerich <madski@unity3d.com> [Fri, 30 Jan 2015 18:51:20 +0100] rev 23972
convert: replace revision references in messages if they are >= short hashes
Convert will try to find references to revisions in commit messages and replace
them with references to the converted revision. It will take any string that
looks like a hash (and thus also decimal numbers) and look it up in the source
repo. If it finds anything, it will use that in the commit message instead.
It would do that for all hex digit sequences of 6 to 40 characters. That was
usually no problem for small repos where it was unlikely that there would be a
matching 6 'digit' hash prefix. It was also no problem on repos with less than
100000 changesets where numbers with 6 or more digits not would match any
revision number. With more than 100000 revisions random numbers in commit
messages would be replaced with a "random" hash. For example, 'handle 100000
requests' would be changed to to 'handle 9117c6 requests'. Convert could thus
not really be used on real repositories with more than 100000 changesets.
The default hash length shown by Mercurial is 12 'digits'. It is unexpected and
unwanted that convert by default tries to replace revision references that use
less than that amount of 'digits'.
To fix this, don't match strings that are less than the default hash size of 12
characters.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 30 Jan 2015 04:59:05 +0900] rev 23971
merge: mark .hgsubstate as possibly dirty before submerge for consistency
Before this patch, failure of updating subrepos may cause inconsistent
".hgsubstate". For example:
1. dirstate entry for ".hgsubstate" of the parent repo is filled
with valid size/date (via "hg state" or so)
2. "hg update" is invoked at the parent repo
3. ".hgsubstate" of the parent repo is updated on the filesystem as
a part of "g"(et) action in "merge.applyupdates"
4. it is assumed that size/date of ".hgsubstate" on the filesystem
aren't changed from ones at (1)
this is not so difficult condition, because just changing hash
ids (every ids are same in length) in ".hgsubstate" doesn't
change the file size of it
5. "subrepo.submerge()" is invoked to update subrepos
6. failure of updating in one of subrepos raises exception
(e.g. "untracked file differs")
7. "hg update" is aborted without updating dirstate of the parent repo
dirstate entry for ".hgsubstate" still holds size/date at (1)
Then, ".hgsubstate" of the parent repo is treated as "CLEAN"
unexpectedly, because updating ".hgsubstate" at (3) doesn't change
size/date of it on the filesystem: see assumption at (4).
This inconsistent ".hgsubstate" status causes unexpected behavior, for
example:
- "hg revert" forgets to revert ".hgsubstate"
- "hg update" misunderstands that (not yet updated) subrepos diverge
(then, it shows the prompt to confirm user's decision)
To avoid inconsistent ".hgsubstate" status above, this patch marks
".hgsubstate" as possibly dirty before "submerge" invocation.
"normallookup"-ed (= dirty) dirstate should be written out, even if
processing is aborted by failure.
This patch marks ".hgsubstate" as possibly dirty before "submerge",
also when it is removed or merged while merging, for safety. This
should prevent Mercurial from misunderstanding inconsistent
".hgsubstate" as clean.
To satisfy conditions at (1) and (4) above, this patch uses "hg status
--config debug.dirstate.delaywrite=2" (to fill valid size/date into
dirstate) and "touch" (to fix date of the file).
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 Jan 2015 12:33:56 +0000] rev 23970
rebase: ensure rebase revision remains visible (issue4504)
Before this changeset rebase was getting very confused if any revision in the
rebase set became hidden. This was fairly easy to achieve if a rebased revision
was made visible by the working copy location. The rebase process would update
somewhere else and the revision would become hidden.
To work around this issue, we ensure rebased revisions remain visible for the
whole process.
This is a simple change suitable for stable. More subtle usage of unfiltered
repository in rebase may solve this issue more cleanly.
Mads Kiilerich <madski@unity3d.com> [Wed, 28 Jan 2015 02:28:39 +0100] rev 23969
extdiff: reintroduce backward compatibility with manual quoting of parameters
72a89cf86fcd broke things ... and the following cleanups didn't fix all issues.
It didn't work with the diffargs shipped in mergetools.rc with explicit
quoting. Parameters would end up with being quoted twice - especially if they
really needed quoting.
To work around that, look for explicit quotes around the variables that will be
substituted with proper quoting. Also accept an additional prefix so we can
handle both
--foo='$parent'
and
'--foo=$parent'
It will however still fail if the user intentionally place the variable inside
a quoted string, as in
'parent $parent is on the left'
There is currently no good way to handle that, short of knowing exactly which
quoting mechanism will be used.
Mads Kiilerich <madski@unity3d.com> [Wed, 28 Jan 2015 02:28:38 +0100] rev 23968
mergetools: drop incorrect quoting of diffargs variables
72a89cf86fcd introduced automatic quoting of diffargs in a not entirely
backwards compatible way. That rendered some of the configuration in
mergetools.rc invalid. It would fail when running extdiff on a single file with
a name that needed quoting.
Before:
$ hg config merge-tools.meld.diffargs
-a --label='$plabel1' $parent --label='$clabel' $child
$ hg --config extdiff.meld= -v --debug meld
running "/usr/bin/meld -a --label=''sp ace@0'' '.../Z.b7a65a1d2f84/sp ace' --label=''sp ace'' '.../sp ace'" in ...
meld: error: too many arguments (wanted 0-3, got 4)
After:
$ hg config merge-tools.meld.diffargs
-a --label=$plabel1 $parent --label=$clabel $child
$ hg --config extdiff.meld= -v --debug meld
running "/usr/bin/meld -a --label='sp ace@0' '.../Z.b7a65a1d2f84/sp ace' --label='sp ace' '.../sp ace'" in ...
(success)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 28 Jan 2015 22:22:59 +0900] rev 23967
namespace: introduce logfmt to show l10n-ed messages for hg log correctly
Before this patch, "_()" is used incorrectly for "tag:" and
"bookmark:" fields. "changeset_printer()" looks up keys composed at
runtime, and it prevents "xgettext" command from getting strings to be
translated from source files.
Then, *.po files merged with updated "hg.pot" lose msgids for "tag:"
and "bookmark:".
This patch introduces "logfmt" information into "namespace" to show
l10n-ed messages "hg log" (or "changeset_printer()") correctly.
For similarity to other namespaces, this patch specifies "logfmt" for
"branches" namespace, even though it isn't needed (branch information
is handled in "changeset_printer()" specially).
To find related code paths out easily, this patch adds "i18n: column
positioning ..." comment to the line composing "logfmt" by default,
even though this line itself doesn't contain any strings to be
translated.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:17:16 -0500] rev 23966
osutil: fix memory leak of PyBytes of path in statfiles
Spotted with cpychecker.
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 19:52:26 -0800] rev 23965
revert: move prefetch to after the actions logic
The prefetch logic came before the actual population of the actions collection,
so it was always being passed an empty action list. This fixes it by moving it
to after that logic.
The only consumer of this function at the moment is remotefilelog, and I
verified it works with this change.
Augie Fackler <raf@durin42.com> [Wed, 28 Jan 2015 13:34:20 -0500] rev 23964
diffhelpers: fix botched return statement from c8e7fa41bfc5
Spotted by Sean Farley using clang.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 27 Jan 2015 20:57:43 -0500] rev 23963
subrepo: don't abort in add when non-hg subrepos are present (issue4513)
This change should have been part of 9994f45ba714.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:14:23 -0500] rev 23962
osutil: fix leak of stat in makestat when Py_BuildValue fails
Spotted with cpychecker.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:12:55 -0500] rev 23961
osutil.c: clean up space before a tab
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:10:04 -0500] rev 23960
dirs: fix leak of iterator in dirs_fromiter
Spotted with cpychecker.
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:07:04 -0500] rev 23959
diffhelpers: verify hline was created before using it
Found with cpychecker.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Jan 2015 22:55:10 -0500] rev 23958
largefiles: revert to lfilesrepo.status() being an unfiltered method
This effectively reverts 67d63ec85eb7, which caused some normal file copies to
not be displayed as copies. Other normal file copies could be displayed- the
exact reason isn't clear. This also adds two tests that were failing prior to
this backout, so that this can be sorted out next cycle.
The difference between copy cases that worked and those that didn't seemed to be
in copies.pathcopies(). When largefiles isn't enabled for the changed test, or
lfstatus is not set in the commands.status() override, 'y.ancestor(x) == x'.
That wasn't true otherwise, which fell through to the _chain() method. In this
case, the copy is removed in the criss cross loop.
'y.ancestor(x)' returns a context.changectx type, while 'x' is a lfilesctx type
in the failing case. I tried adding the ancestor method to the lfilesctx class
to change the type of the ancestor context, however the context when printed as
a string then gains a '+'. This points to it being a context.committablectx,
which clearly isn't correct for an ancestor. Possibly the problem is the
lfilesctx needs to subclass context.committablectx in some cases, but
context.changectx in others, within the same invocation? I'm not sure how to
pull that off, and backing out this change is safer during the freeze.
As to the status changing when a path is specified, I haven't looked into it
yet.
Matt Mackall <mpm@selenic.com> [Sun, 25 Jan 2015 20:13:54 -0600] rev 23957
test-tools: portability tweak
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Jan 2015 20:20:27 +0900] rev 23956
revset: fix ancestors(null) to include null revision (issue4512)
Since 13c0327eeb6f, null parent is explicitly excluded. So, there is no reason
to have nullrev in the initial seen set.
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 13:14:00 +0900] rev 23955
log: use rev() to build revset of --follow option from numeric revision
startrev can be -1.
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 12:56:38 +0900] rev 23954
revset: allow rev(-1) to indicate null revision (BC)
This can simplify the conversion from numeric revision to string. Without it,
we have to handle -1 specially because repo['-1'] != repo[-1].
The -1 revision is not officially documented, but this change makes sense
assuming that "rev(%d)" exists for scripting or third-party tools.
Siddharth Agarwal <sid0@fb.com> [Fri, 23 Jan 2015 20:30:49 -0800] rev 23953
extensions: don't quit loading extensions in the middle if traceback is on
This was introduced way back in 2006 (rev 1f6d520557ec) as sys.exit(0) if
loading an extension failed when --traceback was on, then at some point morphed
into a 'return 1' in a function that otherwise returns nothing.
At this point, if ui.traceback is enabled and if loading an extension fails for
whatever reason, including one as innocent as it not being present, we leave
any extensions loaded so far in a bogus half-initialized state. That doesn't
really make any sense.
Matt Mackall <mpm@selenic.com> [Fri, 23 Jan 2015 17:47:04 -0600] rev 23952
test-hgweb: fix shutdown race
Logfiles weren't necessarily being flushed before being read.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:08:13 +0900] rev 23951
tests: invoke hg command indirectly from shell script to run on Windows
Before this patch, test-tag.t can't run successfully on Windows,
because:
- quoted hg command ('"hg"') prevents "hg.bat" from working correctly
(only at testing with pure Python build)
"%~f0" and "%~dp0hg" in "hg.bat" cause unexpected result in this
case. BTW, quoted "\path\to\hg" works correctly.
- "`pwd`" in the command line is expanded unexpectedly
not "C:\path\to\TESTTMP" but "C;C:\path\to\TESTTMP"
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Jan 2015 15:23:13 -0800] rev 23950
log: evaluate filesets on working copy, not its parent
When running "hg log 'set:added()'", we create two matchers: one used
for producing the revset and one used for finding files to match. In
1fd352aa08fc (graphlog: evaluate FILE/-I/-X filesets on the working
dir, 2012-02-26), we started passing a revision argument along from
what's currently in cmdutil._makelogrevset() to
revset._matchfiles(). When the revision was an empty string, it
referred to the working copy. This was subtly done with "repo[rev or
None]". Then, in f2aeff8a87b6 (revset: avoid recalculating filesets,
2014-10-22), that conversion from empty string to None was lost. Note
that repo[''] is equivalent to repo['.'], not repo[None].
The consequence of this, to the user, is that when running "hg log
'set:added()'", the file matcher matches files added in the working
copy, while the revset matcher matches revisions that touch files
added in the parent of the working copy. As a result, only revisions
that touch any files added in the parent of the working copy will be
considered, but they will only be included if they also touch files
added in the working copy.
Fix the bug by converting '' to None again, but make it a little more
explicit this time (plus, we now have tests for it).
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Jan 2015 15:40:24 -0800] rev 23949
fileset: add tests of generated working copy states
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:55:36 -0500] rev 23948
parsers: avoid leaking several PyObjects in index_stats
Found with cpychecker.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:50:40 -0500] rev 23947
parsers: don't leak a reference to raise_revlog_error on success
Found with cpychecker.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:48:18 -0500] rev 23946
parsers: don't leak a tuple in pack_dirstate
Spotted with cpychecker.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:41:46 -0500] rev 23945
parsers.c: fix a memory leak in index_commonancestorsheads
Spotted with cpychecker.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:33:27 -0500] rev 23944
parsers: avoid leaking obj in index_ancestors
PySequence_GetItem returns a new reference. Found with cpychecker.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:30:21 -0500] rev 23943
parsers: don't leak references to sys et al in check_python_version
Found with cpychecker.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:19:04 -0500] rev 23942
parsers: fix leak of err when asciilower hits a unicode decode error
This is one of many errors detected in parsers.c by cpychecker[1]. I
haven't gone through all of them yet.
1: https://gcc-python-plugin.readthedocs.org/en/latest/index.html
Mads Kiilerich <madski@unity3d.com> [Fri, 23 Jan 2015 18:41:37 +0100] rev 23941
largefiles: use 'default' path for pulling largefiles, not 'default-push'
The put parameter has been unused since day 0.
Mads Kiilerich <madski@unity3d.com> [Fri, 23 Jan 2015 06:28:28 +0100] rev 23940
osx: patch .pax.gz files in pkg bundles so they extract as root (issue4081)
The packages has to be installed by root but they would be installed
insecurely, owned by the uid of the unprivileged user that made the package.
The local user with that uid could thus write to /usr/local/bin/hg .
bdist_mpkg calls out to pax to create the package, but pax do apparently not
have the power to control what it is writing.
Instead, patch the pax files and set their uid fields to 0 before they are
wrapped in a dmg.
Eric Sumner <ericsumner@fb.com> [Wed, 21 Jan 2015 15:54:52 -0800] rev 23939
repair._bundle: fix traceback for bad config value
On IRC, rom1dep reported a traceback[1] from setting
experimental.strip-bundle2-version to True. This diff catches
unexpected values and falls back to the non-experimental bundle1
implementation after issuing a warning.
[1] http://gist.tamytro.org/_admin/gists/qXcdQLwtApgy6e3NwWgl
Mathias De Maré <mathias.demare@gmail.com> [Wed, 21 Jan 2015 21:47:27 +0100] rev 23938
subrepo: correctly add newline for git subrepo diffs
Previously, git subrepo diffs did not have a newline at the end.
This caused multiple subrepo diffs to be joined on the same line.
Additionally, the command prompt after the diff still contained
a part of the diff.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:10:26 +0900] rev 23937
tests: discard useless "(glob)" in "reverting subrepo" lines
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:10:26 +0900] rev 23936
check-code.py: avoid warning against "reverting subrepo ..." lines
Before this patch, "reverting subrepo subrepo/path" lines in *.t test
files require "(glob)", because such lines are recognized as
"reverting path/to/managed/file" by "check-code.py".
On the other hand, "(glob)" for such "reverting ..." line is
recognized as useless by "runt-tests.py", because subrepo paths shown
in such lines are always normalized by "util.pconvert". And this
causes "no result code from test" warning.
As a preparation for discarding "(glob)" from such lines in subsequent
patch, this patch avoids warning against them, by adding negative
lookahead assertion "(?!subrepo )" to the regexp.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:07:06 +0900] rev 23935
run-tests.py: inherit --pure option from outer run-tests.py execution
Before this patch, "test-run-tests.t" doesn't test "run-tests.py" with
"--pure", even if outer "run-tests.py" is executed with it.
This patch uses not "HG_RUN_TESTS_PURE" but "HGTEST_RUN_TESTS_PURE",
because "HG_" prefixed environments are forcibly dropped in "_getenv()".
This is also useful to run "run-tests.py" successfully by
"run-tests.py --pure" on Windows without any compilation tools (like
VisualStudio).
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:07:06 +0900] rev 23934
hg.bat: return exit code explicitly for indirect invocation
When "hg.bat" is invoked via interactive shell "cmd.exe" on Windows,
it can store own exit code into ERRORLEVEL correctly, regardless of
explicit "exit" statement in it: "cmd.exe" seems to hold ERRORLEVEL
updated by the last command in the batch file (= "python hg", in
"hg.bat" case).
On the other hand, "hg.bat" is invoked indirectly via
"subprocess.Popen" (e.g. shell alias, hooks, hgclient and so on), the
parent process always receives exit code 0 from spawned "hg.bat":
batch files on Windows seem not to be really spawned like as shell
scripts on UNIX, but to be executed in the "cmd.exe" process.
This patch returns exit code explicitly for indirect invocation.
"/b" should be specified for "exit" to prevent "cmd.exe" from being
terminated when "hg.bat" is invoked interactively from it.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:03:58 +0900] rev 23933
run-tests.py: execute hghave with same env vars as ones for actual tests
Before this patch, "run-tests.py" executes "hghave" process without
any modifications for environment variables, even though actual tests
are executed with LC_ALL, LANG and LANGUAGE explicitly assigned "C".
When "run-tests.py" is executed:
- with non-"C" locale environment variables on any platforms, or
- without any explicit locale environment setting on Windows
(only for "outer-repo" feature using "hg root")
external commands indirectly executed by "hghave" may show translated
messages.
This causes incorrect "hghave" result and skipping tests, because some
regexp matching of "hghave" expect external commands to show
un-translated messages.
To prevent external commands from showing translated messages, this
patch makes "run-tests.py" execute "hghave" with same environment
variables as ones for actual tests.
This patch doesn't make "hghave" execute external commands forcibly
with LC_ALL, LANG and LANGUAGE explicitly assigned "C", because
changing "run-tests.py" is cheaper than changing "hghave":
- "os.popen" should be replaced by "subprocess.Popen" or so, and
- setting up environment variables should be newly added
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 05:04:48 +0100] rev 23932
osx: use bdist_mpkg.script_bdist_mpkg module instead of bdist_mpkg command
It seems like a default installation of bdist_mpkg makes it available as
Python module, but the corresponding executable is placed in a location like
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/bin which is
not in $PATH and thus not directly available. 'make osx' would thus fail.
Instead, skip the bdist_mpkg executable and invoke it as a Python module. That
works out of the box here.
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 05:04:46 +0100] rev 23931
osx: don't launch installer after building it with bdist_mpkg
bdist_mpkg do for some reason default to use the parameter --show ("Open with
Installer.app after building") if no parameters are specified. We do not like
that.
All the important parameters to bdist_mpkg are already specified in setup.py
and we don't have any to specify in the Makefile.
Instead, specify the parameter '--' which do no harm but will disable the
default opening of the installer. This makes it possible to build packages
"silently".
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 05:01:01 +0100] rev 23930
osx: update "Read Me" "Important Information" text in the package installer
Nothing fancy here, just making the text less specific and less wrong by not
mentioning OS X version and Python versions and wrong URLs.
Ryan McElroy <rmcelroy@fb.com> [Tue, 20 Jan 2015 15:05:44 -0800] rev 23929
commit: remove reverse search for copy source when not in parent (issue4476)
Previously, we had weird, nonsensical behavior when committing a file move
with a missing source. This removes that weird logic and tests that the bug
this strange behavior caused is fixed. Also adds a longish comment to prevent
some poor soul from accidentally re-implementing the bug in the future.
Matt Mackall <mpm@selenic.com> [Tue, 20 Jan 2015 14:51:11 -0800] rev 23928
merge with i18n
Wagner Bruna <wbruna@yahoo.com> [Sun, 18 Jan 2015 11:16:45 -0200] rev 23927
i18n-pt_BR: synchronized with db8e3f7948b1
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 22:21:53 -0500] rev 23926
convert: handle LookupError in mercurial_source.lookuprev()
This is in line with the documentation on the base class method, and is related
to issue4496 (but doesn't fix the reporter's problem of not mangling other data
that matches a revision pattern). Now instead of aborting when there is an
ambiguous source rev, it simply won't update the commit comment. A warning
message might be nice, but a None return masks whether the problem was no
matching revision, or more than one.
The only other caller of this is the logic that converts tags, but those are
never ambiguous since they are always 40 characters.
A test isn't feasible because there simply aren't enough commits in the test
suite repos to have an ambiguous identifier that is at least 6 characters long,
and it would be too easy for the ambiguity to disappear when unrelated changes
are made. Instead, I simply ran 'hg --traceback log -r c' on the hg repo, and
handled the error it threw.
Sean Farley <sean.michael.farley@gmail.com> [Sun, 18 Jan 2015 22:24:14 -0800] rev 23925
color: add missing 'dim' in _effects
It seems that this has been missing for people running in 'ansi' mode.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 17 Jan 2015 15:03:41 -0800] rev 23924
diff: use binary diff when copy source is binary
When a binary source has been copied or renamed into a non-binary
file, we don't check whether the copy source was binary. There is a
code comment explaining that a git mode will be forced anyway in order
to capture the copy record (i.e. losedatafn() will be called). This is
true, but forcing git mode is not the only effect binary files have:
when git mode was already requested, we use the binary-ness to tell us
whether to use a regular unified diff or a git binary diff. The user
sees this as a "Binary file $file has changed" instead of the binary
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 15:15:40 -0500] rev 23923
largefiles: fix commit of a directory with no largefile changes (issue4330)
When a directory is named in the commit file list, the previous behavior was to
walk the list, and if no normal files in the directory were also named, add the
corresponding standin for each largefile in that directory. The directory is
then dropped from the list, so that committing a directory with no normal file
changes works. It then added the corresponding standin directory for the first
largefile seen, by prefixing it with '.hglf/'.
The latter is unnecessary since each affected largefile is explicitly referenced
by its standin in the list. It also caused an abort if there were no changed
largefiles in the directory, because none of its standins changed:
abort: .hglf/foo/bar: no match under directory!
This list of files is used to tweak a matcher in lfutil.updatestandinsbymatch(),
which is what is passed to commit().
The status() call that is ultimately done in the commit code with this matcher
seems to have some OS specific differences. It is not necessary to append '.'
for Windows to run the largefiles tests cleanly. But if '.' is not added to the
list, the match function isn't called on Linux, so status() would miss any
normal files that were also in a named directory. The commit then proceeds
without those normal files, or says "nothing changed" if there were no changed
largefiles in the directory. This is not filesystem specific, as VFAT on Linux
had the same behavior as when run on ext4. It is also not an issue with
lfilesrepo.status(), since that only calls the overridden implementation when
paths are passed to commit. I dont have access to an OS X machine ATM to test
there.
Maybe there's a better way to do this. But since the standin directory for the
first largefile was previously being added, and that caused the same walk in
status(), there's no preformance change to this. There is no danger of
erroneously committing files in '.', because the original match function is
called, and if it fails, the lfutil.updatestandinsbymatch() tweaked matcher only
indicates a match if the file is in the list of standins- and '.' never is. The
added tests confirm this.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 16:38:56 -0500] rev 23922
test-tools: update for platforms without symlink support after 5b20e4c32117
The change was triggered by removing the 'baz' hardlink.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 16:33:41 -0500] rev 23921
tests: add "(glob)" to output in test-histedit-commute.t for Windows
This goes with the changes in 3831e9b3750a.
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:29:30 -0800] rev 23920
Added signature for changeset db8e3f7948b1
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:29:05 -0800] rev 23919
Added tag 3.3-rc for changeset db8e3f7948b1
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:28:30 -0800] rev 23918
merge default into stable for 3.3 feature freeze
Wagner Bruna <wbruna@yahoo.com> [Sat, 17 Jan 2015 22:01:14 -0200] rev 23917
messages: quote "hg help" hints consistently
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:08:47 -0800] rev 23916
bundle2: fix parttype enforcement
As spotted by Malte Helmert.
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 17:59:30 -0800] rev 23915
test-tools: another vfat fix
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 15:54:03 -0800] rev 23914
test-tools: check for unix permissions for hardlinking
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 15:28:56 -0800] rev 23913
tests: more fixes for f
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:53:56 -0800] rev 23912
tests: teach f not to report symlink mode bits
They're not meaningful or portable
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:53:16 -0800] rev 23911
tests: teach f not to report directory size
It's not meaningful or portable
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:44:43 -0800] rev 23910
test-histedit-commute: call helper script with sh
Buildbot pointed out that this test wasn't passing on Linux+vfat
because there's no chmod for shell scripts.
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:38:17 -0800] rev 23909
test-tools: fix portability issues
Solomon Matthews <smat@fb.com> [Sat, 17 Jan 2015 13:13:16 -0800] rev 23908
progress: add a lock to prepare for introducing a thread
Solomon Matthews <smat@fb.com> [Sat, 17 Jan 2015 13:10:37 -0800] rev 23907
progress: move update check into helper method
Solomon Matthews <smat@fb.com> [Sat, 17 Jan 2015 13:09:33 -0800] rev 23906
progress: move current topic to member variable
Solomon Matthews <smat@fb.com> [Thu, 15 Jan 2015 20:03:28 -0800] rev 23905
progress: add try/finally to make the diffs for the next commit more readable
No change in behavior.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 16 Jan 2015 18:34:14 -0800] rev 23904
transaction: include backup file in the "undo" transaction
Once the transaction is closed, we now write transaction related data for
possible future undo. For now, we only do it for full file "backup" because
their were not handle at all in that case. In the future, we could move all the
current logic to set undo up (that currently exists in localrepository) inside
transaction itself, but it is not strictly requires to solve the current
situation.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 16 Jan 2015 19:35:04 -0800] rev 23903
transaction: pass the name of the "undo" journal to the transaction
It is time for the transaction to be responsible for setting up the
undo data. It is necessary to move this logic into the transaction
because many more files are handled now, and the transaction is the
object tracking them all.
The value can be set to None if no undo should be set.