- Jul 31, 2012
-
-
Matt Harbison authored
Previous to this, 'commit -A' would add as normal files, files that were already committed as largefiles, resulting in files being listed twice by 'status -A'. It also missed when (only) a largefile was deleted, even though status reported it as '!'. This also has the side effect of properly reporting the state of the affected largefiles in the post commit hook after a remove that also affected a normal file (the largefiles used to be 'R', now are properly absent). Since scmutil.addremove() is called both by the ui command (after some trivial argument validation) and during the commit process when -A is specified, it seems like a more appropriate method to wrap than the addremove command. Currently, a repo is only enabled to use largefiles after an add that explicitly identifies some file as large, and a subsequent commit. Therefore, this patch only changes behavior after such a largefile enabling commit. Note that in the test, if the final commit had a '-v', 'removing large8' would be printed twice. Both of these originate in removelargefiles(). The first print is in verbose mode after traversing remove + forget, the second is because the '_isaddremove' attr is set and 'after' is not.
-
- Sep 18, 2012
-
-
Katsunori FUJIWARA authored
Before this patch, zip archives created by "hg archive" are extracted with unexpected timestamp, if TZ is not configured as GMT. This patch adds "extended-timestamp" extra block to zip archives, and unzip will extract such archives with timestamp specified in added extra block, even though TZ is not configured as GMT. Please see documents below for detail about specification of zip file format and "extended-timestamp" extra block: http://www.pkware.com/documents/casestudies/APPNOTE.TXT http://www.opensource.apple.com/source/zip/zip-6/unzip/unzip/proginfo/extra.fld Original implementation of this patch was suggested by "Jun Omae <jun66j5@gmail.com>".
-
- Sep 09, 2012
-
-
Matt Harbison authored
This allows the wrapped command's validation code to run (which is currently only to ensure 'noupdate' and 'updaterev' aren't both specified), the copy/pasted unpacking of hg.clone() args to be removed, and any future changes to the base command (however unlikely) to be inherited by largefiles. Unfortunately, the command override can't be swapped entirely for an hg.clone() override because the extra --all-largefiles arg needs to be injected. It also isn't enough to call the wrapped clone command and leave the caching code after it, because the file caching code needs access to the destination repo, which is only available from hg.clone(). An alternative would be to use the dest path in the clone command override to re-obtain a reference to the repo. A slight deviation from the regular hg.clone() function is that the repo is NOT deleted if the caching fails, but that was also the previous behavior. Maybe it should for consistency?
-
Matt Harbison authored
A status message is output if hg.clone() determines the default destination because None was provided. The previous code never passed None to hg.clone().
-
Matt Harbison authored
This was broken when restoring normal -u and -U functionality.
-
- Sep 08, 2012
-
-
Matt Harbison authored
Previously, tip would be checked out regardless of the -u or -U parameter. I'm not sure what the 'required for successful walkchangerevs' comment meant, but it appears to reference code which has since moved to downloadlfiles() in 7d6a660ca151. Perhaps it was to force caching when the -U parameter is given? The price of this change is that -U --all-largefiles won't cache anything. That will be fixed next. Note that X + Y in the 'X largefiles updated, n removed' and 'Y additional largefiles cached' lines do not add up to the same values in these tests, but all of the largefiles have been downloaded. The reason being that several largefiles have the same content (eb7338044 is pointed to by sub/large2, large3 and sub/large4). In the 'clone -u 1' operation, this largefile is cached to populate the working directory, even without --all-largefiles. That means the file isn't downloaded again and cached in the rev where large3 and sub/large4 both point to this file. Downloading that one file in that one rev seems to be counted twice with 'clone -u 0'. (Maybe it is also being downloaded twice?)
-
- Sep 18, 2012
-
-
Thomas Arendsen Hein authored
With the default branch this will cause warnings from check-code.
-
- Sep 17, 2012
-
-
Matt Mackall authored
-
Tim Delaney authored
hgweb has an incorrect padding calculation, causing the text to move further away from the graph the more branches there are (issue3626). This patch fixes all existing templates (gitweb, monoblue, paper and spartan). Tests updated by Patrick Mezard <patrick@mezard.eu>
-
- Sep 06, 2012
-
-
Matt Harbison authored
This maintains the exit codes documented in commands.py.
-
Matt Harbison authored
-
Matt Harbison authored
-
- Sep 10, 2012
-
-
Matt Harbison authored
This maintains the exit codes documented in commands.py.
-
- Sep 06, 2012
-
-
Matt Harbison authored
This maintains the exit codes documented in commands.py.
-
- Sep 11, 2012
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Sep 10, 2012
-
-
Martin Schröder authored
-
- Sep 03, 2012
-
-
Jim Hague authored
Some shells, e.g. ksh89, will emit \" in a here document as ", while others will emit \". To be sure of getting \", we specify \\". This gets test-commit-amend.t and test-largefiles.t working on AIX.
-
- Aug 30, 2012
-
-
Pierre-Yves David authored
New commit from the amend process were created without any phase contraint. If the amended changeset had a different phase from it's parent, the phases data were lost. The changeset ensure the new commit are created in the same phase than the original changeset.
-
- Sep 06, 2012
-
-
Takumi IINO authored
-
- Sep 04, 2012
-
-
Bryan O'Sullivan authored
-
Bryan O'Sullivan authored
Subversion 1.7 changes its XML output to include an explicit encoding tag: <?xml version="1.0" encoding="UTF-8"?> This triggers xml.dom.minidom to always return unicode strings, causing other parts of the code to explode. We unconditionally encode path names before handing them back, which works with both str (actually a no-op) and unicode values.
-
Bryan O'Sullivan authored
-
Bryan O'Sullivan authored
-
- Aug 31, 2012
-
-
Pierre-Yves David authored
The `repair` code builds a giant revset query instead of using the "%lr" idiom. It is inefficient and crash when the number of stripped changeset is too big. This changeset replaces the bad code by a better revset usage.
-
- Aug 02, 2012
-
-
Pierre-Yves David authored
The standard reaction in from of unexpected vimdiff is to ":quit". This will make vimdiff return a 0 status even if no merge were done at all. This change detect that nothing have been changed in vimdiff as a potential unresolved conflict.
-
- Aug 29, 2012
-
-
kiilerix authored
JavaScript .replace always magically processed $$ $& $' $` in replacement strings and thus displayed subject lines incorrectly in the graph view. Instead of regexps and .replace we now just create the strings the right way in the first place.
-
Steve Borho authored
-
- Sep 01, 2012
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Martin Schröder authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Aug 03, 2012
-
-
Patrick Mézard authored
Avoid mixing popen and subprocess calls, it simplifies the command line generation and quoting issues with redirections. In practice, it fixes the subversion sink on Windows and probably helps with monotone and darcs sources.
-
Patrick Mézard authored
-
- Aug 15, 2012
-
-
Matt Harbison authored
This fixes a traceback when pushing to a local repo which started with 9e1616307c4c.
-
- Aug 31, 2012
-
-
Pierre-Yves David authored
The `repair` code builds a giant revset query instead of using the "%lr" idiom. It is inefficient and crash when the number of stripped changeset is too big. This changeset replaces the bad code by a better revset usage.
-
- Sep 01, 2012
-
-
Matt Mackall authored
-
- Aug 27, 2012
-
-
Katsunori FUJIWARA authored
-