- Jul 31, 2012
-
-
Patrick Mézard authored
Displaying multiple synopsis in online help has been broken since Matt RST refactoring, around ff26712a0c50. Rebase help is apparently the only one using this trick, just drop the second synopsis and assume people will understand as with graft help.
-
- Aug 01, 2012
-
-
Patrick Mézard authored
- Append an EOL - State the changeset is skipped
-
- Jul 31, 2012
-
-
Patrick Mézard authored
If patch.patch() reports patched files when applying a changeset and the following commit says nothing changed, transplant used to abort with a RuntimeError, assuming something went wrong with patching. The mismatch is patch.patch() reports patched files, not changed ones. It could be modified to report changed files but it means duplicating work from status, may be expensive in the case of binary files, and is probably not that useful at API level. For instance, if two patches are applied on the working directory, the outcome may be nothing changed while each call would have returned modified files. The caller would have to call status() itself again. This patch fixes the issue by trusting patching code: if the patch succeeded and commit reports nothing changed, then nothing changed, patch() did not "dropped changes on the floor".
-
- Jul 29, 2012
-
-
Katsunori FUJIWARA authored
"i18n.gettext()" invocation for "editcomment" itself should have little impact for whole initialization cost of histedit, because it is already invoked for initialization of the command table entry. '\n\n' has to be added to the text being edited separately from "editcomment", because leading 'line feed' characters are not exported to "hg.pot" file correctly.
-
- Jul 31, 2012
-
-
Thomas Arendsen Hein authored
Using less -S will hide possibly important information when reviewing a changeset, e.g. something wrong/dangerous after the 80th column, because "less" will not give an indication that following characters are hidden.
-
kiilerix authored
-
- Jul 30, 2012
-
-
kiilerix authored
test-histedit-edit.t failed because Solaris sed strips lines not ending with \n.
-
- Jul 28, 2012
-
-
Simon Heimberg authored
-
- Jul 29, 2012
-
-
Katsunori FUJIWARA authored
Before this patch, updating statistics line appears at the bottom of the examples describing rules to edit history. But such line never appear in the file describing rules while histedit-ing, so this patch removes that line from the examples.
-
- Jul 20, 2012
-
-
Matt Harbison authored
Previous to this, outgoing with a revset succeeded unless --large was also specified.
-
- Jul 21, 2012
-
-
Matt Harbison authored
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?
-
- Jul 20, 2012
-
-
Matt Harbison authored
Previous to this, cat only accepted revsets if the largefiles extension was disabled.
-
Matt Harbison authored
Previous to this, revert only accepted revsets if the largefiles extension was disabled.
-
- Jul 25, 2012
-
-
Katsunori FUJIWARA authored
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.
-
- Jul 27, 2012
-
-
Matt Mackall authored
Properly fixing this is quite a bit trickier.
-
- Jul 26, 2012
-
-
kiilerix authored
-
- Jul 06, 2012
-
-
Michael Bacarella authored
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.
-
- Jul 26, 2012
-
-
Patrick Mézard authored
test-convert-svn-sink.t still pass and I tested pushing to an svn+ssh repository
-
- Jul 23, 2012
-
-
Matt Harbison authored
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
-
- Jul 25, 2012
-
-
Patrick Mézard authored
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.
-
Patrick Mézard authored
This is convenient when running tests dumping the editor content, it avoids the following output line to be mixed with histedit message.
-
- Jul 21, 2012
-
-
Matt Harbison authored
-
- Jul 20, 2012
-
-
Matt Harbison authored
An easy way to force this (and cause a traceback) prior to the fix for 3507 was $ touch large $ hg add --large large $ hg ci -m "add" $ hg remove large $ touch large $ hg addremove --config largefiles.patterns=**large This patch also detected (and corrected) a previous test where a standin got added as a largefile (without a traceback).
-
- Jul 19, 2012
-
-
Matt Harbison authored
The problem only occurred if a file was removed with 'hg rm' (as opposed to the OS utilities), and then addremove was run before a commit. Both normal and large files were affected. Ensuring that the file exists prior to an lstat() for size seems like the Right Thing. But oddly enough, the missing file that was causing lstat() to blow up was a standin when a largefile was removed, which seems fishy, because a standin should never be added as a largefile. I was then able to get a standin added as a largefile (whose name is 'large') with hg addremove --config largefiles.patterns=**large which also causes a backtrace. That will be fixed next.
-
Matt Harbison authored
The example in comment #9 of the bug writeup must be run exactly- it was the commit after the rm and prior to the addremove that screwed things up, because that commit noticed that the largefile was missing, called drop(), and then the original commit function did nothing (due to the file in the '!' state). The addremove command properly put it into the 'R' state, but it remained stuck in that state (because commit insisted 'nothing changed'). Without the commit prior to addremove, the problem didn't occur. Maybe this is an indication that lfdirstate needs to take a few more hints from the regular dirstate, regardless of what _it_ thinks the state is- similar inconsistency is probably still possible with this patch if the original commit succeeds but the lfdirstate write fails.
-
Matt Harbison authored
If a file was missing, the missing list contained a path relative to the repo. When building the matcher from that list, the file name ended up concatenated to cwd, causing the command to abort with '<file> not under root'. This rebuilds the missing list with paths relative to cwd.
-
- Jul 13, 2012
-
-
Peter Arrenbrecht authored
This change separates peer implementations from the repository implementation. localpeer currently is a simple pass-through to localrepository, except for legacy calls, which have already been removed from localpeer. This ensures that the local client code only uses the most modern peer API when talking to local repos. Peers have a .local() method which returns either None or the underlying localrepository (or descendant thereof). Repos have a .peer() method to return a freshly constructed localpeer. The latter is used by hg.peer(), and also to allow folks to pass either a peer or a repo to some generic helper methods. We might want to get rid of .peer() eventually. The only user of locallegacypeer is debugdiscovery, which uses it to pose as a pre-setdiscovery client. But we decided to leave the old API defined in locallegacypeer for clarity and maybe for other uses in the future. It might be nice to actually define the peer API directly in peer.py as stub methods. One problem there is, however, that localpeer implements lock/addchangegroup, whereas the true remote peers implement unbundle. It might be desireable to get rid of this distinction eventually.
-
Sune Foldager authored
This introduces a peer method into all repository classes, which currently simply returns self. It also changes hg.repository so it now raises an exception if the supplied paths does not resolve to a localrepo or descendant. Finally, all call sites are changed to use the peer and local methods as appropriate, where peer is used whenever the code is dealing with a remote repository (even if it's on local disk).
-
- Jul 16, 2012
-
-
Patrick Mézard authored
-
- Jul 11, 2012
-
-
Patrick Mézard authored
-
- Jul 14, 2012
-
-
Patrick Mézard authored
The glog command is preserved in the extension for backward compatibility.
-
Patrick Mézard authored
-
- Jul 11, 2012
-
-
Patrick Mézard authored
-
- Jun 24, 2012
-
-
Patrick Mézard authored
Another version could have returned a revset expression from getoutgoing(), but we do not know how many times it will be resolved, so better do it once explicitely.
-
Patrick Mézard authored
With --outgoing, input revisions were passed to getoutgoing() before being resolved.
-
- Jul 14, 2012
-
-
Patrick Mézard authored
getoutgoing() is just rewritten almost like revset.outgoing(), a follow-up will make it use revsets after the tests are adjusted.
-
- Jul 15, 2012
-
-
Matt Mackall authored
-
- Jul 06, 2012
-
-
Wagner Bruna authored
When the source repository had a revision renaming "$new -> $old", but the filemap a "$old -> $new" rename, the converted revision could use either $new (deleting the file) or $old (keeping the file) when getting the file data, depending on the lexicographical order of those names. So the resulting revision would leave some files untouched (as expected), but delete others arbitrarely.
-
- Jul 11, 2012
-
-
Patrick Mézard authored
It was introduced by d9acbe7b0049, returned by asciiformat() but never read anywhere. 20140c249e63 stopped using it completely, and the graphmod.CHANGESET type is passed through all functions.
-
Patrick Mézard authored
-