Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 19:08:26 -0400] rev 17271
largefiles: support revsets for outgoing --large
Previous to this, outgoing with a revset succeeded unless --large was also
specified.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 23:50:52 -0400] rev 17270
largefiles: fix a traceback introduced with recent peer changes
Changeset
1ac628cd7113 broke 'outgoing --large'
...
File "hgext\largefiles\lfutil.py", line 56, in findoutgoing
remote.local(), force=force)
File "mercurial\discovery.py", line 31, in findcommonincoming
if not remote.capable('getbundle'):
AttributeError: 'lfilesrepo' object has no attribute 'capable'
This restores the previous functionality, though I'm not sure if there's a
better way to do this- that changeset introduces a hunk in debugdiscovery that
does this:
if not util.safehasattr(remote, 'branches'):
# enable in-client legacy support
remote = localrepo.locallegacypeer(remote.local())
Is there a legacy support issue here too?
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 19:14:41 -0400] rev 17269
largefiles: support revsets for cat
Previous to this, cat only accepted revsets if the largefiles extension was
disabled.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 18:13:19 -0400] rev 17268
largefiles: support revsets for revert
Previous to this, revert only accepted revsets if the largefiles extension was
disabled.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 25 Jul 2012 16:40:38 +0900] rev 17267
doc: unify section level between help topics
Some help topics use "-" for the top level underlining section mark,
but "-" is used also for the top level categorization in generated
documents: "hg.1.html", for example.
So, TOC in such documents contain "sections in each topics", too.
This patch changes underlining section mark in some help topics to
unify section level in generated documents.
After this patching, levels of each section marks are:
level0
""""""
level1
======
level2
------
level3
......
level4
######
And use of section markers in each documents are:
- mercurial/help/*.txt can use level1 or more
(now these use level1 and level2)
- help for core commands can use level2 or more
(now these use no section marker)
- descriptions of extensions can use level2 or more
(now hgext/acl uses level2)
- help for commands defined in extension can use level4 or more
(now "convert" of hgext/convert uses level4)
"Level0" is used as top level categorization only in "doc/hg.1.txt"
and the intermediate file generated by "doc/gendoc.py", so end users
don't see it in "hg help" outoput and so on.
Patrick Mezard <patrick@mezard.eu> [Mon, 23 Jul 2012 19:03:32 +0200] rev 17266
addremove: mention --similarity defaults to 100 (
issue3430)
Greg Ward <greg@gerg.ca> [Wed, 25 Jul 2012 22:41:26 -0400] rev 17265
revset: polish explanation of the difference between file() and filelog()
Augie Fackler <raf@durin42.com> [Thu, 26 Jul 2012 16:57:50 -0500] rev 17264
strip: move bookmarks to nearest ancestor rather than '.'
If you've got this graph:
0-1-2
\
3
and 3 is checked out, 2 is bookmarked with "broken", and you do "hg
strip 2", the bookmark will move to 3, not 1. That's always struck me
as a bug.
This change makes bookmarks move to the tipmost ancestor of
the stripped set rather than the currently-checked-out revision, which
is what I always expected should happen.
Matt Mackall <mpm@selenic.com> [Fri, 27 Jul 2012 12:33:48 -0500] rev 17263
largefiles: fix exception hack for i18n (
issue3197)
Properly fixing this is quite a bit trickier.
Matt Mackall <mpm@selenic.com> [Fri, 27 Jul 2012 12:32:02 -0500] rev 17262
merge with crew
Patrick Mezard <patrick@mezard.eu> [Fri, 27 Jul 2012 17:48:49 +0200] rev 17261
webcommands: do not modify repo.tagslist()
Repeatedly refreshing a gitweb summary page served by hg serve would
show the tags list switching between two different sequences.
Brad Hall <bhall@fb.com> [Tue, 05 Jun 2012 17:00:13 -0700] rev 17260
tag: don't allow tagging the null revision (
issue1915)
Also fixed the tests that were doing this and expected it to work
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 26 Jul 2012 13:58:43 +0900] rev 17259
i18n: add/relocate "i18n keyword" comments for i18n messages in revset.py
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 26 Jul 2012 13:58:43 +0900] rev 17258
revset: use appropriate predicate name in error messages
"extinct" and "unstable" predicates use "obsolete" implementation
internally, but own predicate name should be used in error messages of
them instead of "obsolete".
Adrian Buehlmann <adrian@cadifra.com> [Thu, 26 Jul 2012 23:08:34 +0200] rev 17257
test-histedit-fold: fix for Windows
Fixes
336121088ef1 failing with MSYS.
MSYS sh.exe mangled that path by applying its path magic, which caused the
test to fail on Windows.
Matt Mackall <mpm@selenic.com> [Thu, 26 Jul 2012 17:04:01 -0500] rev 17256
tags: visit new heads in forward order when rebuilding cache
This improves performance of building the tag cache by 4x on a repo
with ~2800 heads.
Patrick Mezard <patrick@mezard.eu> [Fri, 27 Jul 2012 13:56:19 +0200] rev 17255
identity: show trailing '+' for dirty subrepos (
issue2839)
Patrick Mezard <patrick@mezard.eu> [Fri, 27 Jul 2012 10:16:20 +0200] rev 17254
discovery: fix invalid comment about extinct being ignored
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 26 Jul 2012 16:21:43 +0200] rev 17253
obsolete: fix decoding error message arguments
Patrick Mezard <patrick@mezard.eu> [Tue, 24 Jul 2012 21:20:56 +0200] rev 17252
push: do not try to push remote obsolete if local has none
Mads Kiilerich <mads@kiilerich.com> [Thu, 26 Jul 2012 02:54:13 +0200] rev 17251
help: fix some instances of 'the the'
Michael Bacarella <mbacarella@janestreet.com> [Fri, 06 Jul 2012 18:06:52 -0400] rev 17250
pager: work around bug in python 2.4's subprocess module (
issue3533)
hg v2.2.2 fixed the pager on Windows, but broke it on Python 2.4.
This patch only uses the new behavior if Python >= 2.5 is detected.
Pierre-Yves.David@ens-lyon.org [Wed, 25 Jul 2012 19:02:35 +0200] rev 17249
clone: copy obsolete markers during local clone
This change adds `obsstore` to the list of files copied by local clone,
until now changesets were copied without their obsolete markers.
Note: extinct changesets were and are still included by such clones to
enable hardlinking. There is no obvious reason to prevent their exchange
here.
Rebased by Patrick Mezard <patrick@mezard.eu>
Patrick Mezard <patrick@mezard.eu> [Wed, 25 Jul 2012 19:34:31 +0200] rev 17248
discovery: add extinct changesets to outgoing.excluded
Before this change, push would incorrectly fast-path the bundle
generation when extinct changesets are involved, because they are not
added to outgoing.excluded. The reason to do so are related to
outgoing.excluded being assumed to contain only secret changesets by
scmutil.nochangesfound(), when displaying warnings like:
changes found (ignored 9 secret changesets)
Still, outgoing.excluded seems like a good API to report the extinct
changesets instead of dedicated code and nothing in the docstring
indicates it to be bound to secret changesets. This patch adds extinct
changesets to outgoing.excluded and fixes scmutil.nochangesfound() to
filter the excluded node list.
Original version and test by Pierre-Yves.David@ens-lyon.org
Patrick Mezard <patrick@mezard.eu> [Thu, 26 Jul 2012 12:07:55 +0200] rev 17247
convert/svn: handle non-local svn destination paths (
issue3142)
test-convert-svn-sink.t still pass and I tested pushing to an svn+ssh
repository
Adrian Buehlmann <adrian@cadifra.com> [Wed, 25 Jul 2012 16:50:22 +0200] rev 17246
setup: fix build_hgexe for mingw32 compiler
Fixes
python setup.py build_hgexe -i --compiler=mingw32
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Jul 2012 23:37:53 -0400] rev 17245
largefiles: fix path handling for cp/mv (
issue3516)
Previously, a copy or a move of a largefile only worked if the cwd was the root
of the repository. The first issue was that the destination path passed to
os.mkdirs() chopped the absolute path to the standin after '.hglf/', which
essentially created a path relative to the repository root. Similarly, the
second issue was that the source and dest paths for copyfile() were relative to
the repo root. This converts these three paths to absolute paths.
Some notable issues, regardless of the directory in which the cp/mv is executed:
1) The copy is not being recorded in lfdirstate, but it is in dirstate for the
standins. I'm not sure if this is by design (i.e. minimal info in lfdirstate).
2) status -C doesn't behave as expected. Using the testcase as an example:
# after mv + ci
$ hg status -C -v --rev '.^' # expected to see 'A' and ' ' lines too
R dira\dirb\largefile
$ hg status -C -v --rev '.^' foo/largefile
# no output # expected to see 'A' and ' ' lines only
$ hg status -C -v --rev '.^' foo/
# no output # expected to see 'A', ' ' and 'R' lines
$ hg status -C -v --rev '.^' ./ # expected to see 'A' and ' ' lines too
R dirb\largefile
$ hg status -C -v --rev '.^' ../.hglf/dira/foo/largefile
A ..\.hglf\dira\foo\largefile
..\.hglf\dira\dirb\largefile # no 'R' expected when new file is specified
$ hg status -C -v --rev '.^' ../.hglf # OK
A ..\.hglf\dira\foo\largefile
..\.hglf\dira\dirb\largefile
R ..\.hglf\dira\dirb\largefile
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 25 Jul 2012 16:15:28 +0900] rev 17244
revset: add explanation about difference between 'filelog()' and 'file()'
Matt Mackall <mpm@selenic.com> [Wed, 25 Jul 2012 14:49:53 -0500] rev 17243
hgweb: improve colors for comparison page
delete: red -> red
insert: green -> yellow
change: yellow -> gray
Patrick Mezard <patrick@mezard.eu> [Wed, 25 Jul 2012 16:27:26 +0200] rev 17242
histedit: fix new nodes computation with --continue (
issue3534)
When running the following actions:
pick
617f94f13c0f 1 +4
drop
888f9082bf99 2 +5
fold
251d831eeec5 3 +6
if the fold fails, is fixed by the user with a new changeset, --continue
will ignore the new revision when generating the fold changelog. This
was caused by --continue detecting new changesets as descendants of the
parent not descendants of changesets in the initial list. In this case,
dropped changesets must be ignored.
Even with the computation fixed, the 'newchildren' list was always
emptied by the filtering loop and passed empty to finishfold().
Note that changesets dropped and recreated identically will still be
missed. This probably cannot be solved but is unlikely to happen.
Other things, like 'newchildren' having multiple heads, should be
checked as well.