- Jan 06, 2012
-
-
Pierre-Yves David authored
``{phaseidx}`` is providing the phase index as integer. This integer representation is useful when people need to use the fact that phase are ordered. Test keep using the number version for readability purpose.
-
- Dec 29, 2011
-
-
Pierre-Yves David authored
-
- Jan 04, 2012
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
The bugs seemed to show up when element not in future common changeset should hold new hold phase data. The whole phase push machinery was rewritten in the process.
-
- Jan 06, 2012
-
-
Pierre-Yves David authored
This changeset adds ``public()``, ``draft()`` and ``secret`` symbol for revset.
-
Pierre-Yves David authored
Phases constant are named after the phase name. Usage of integer have been replaced by proper constant.
-
- Jan 09, 2012
-
-
kiilerix authored
According to the documentation SSLSocket.getpeercert() can return None.
-
kiilerix authored
The previous workaround for correct handling of wrapping of failing connections might be enough to prevent this from happening, but the check here makes this function more robust.
-
kiilerix authored
-
kiilerix authored
-
kiilerix authored
This simplifies the code and makes the flow more obvious and reduces the indentation level.
-
kiilerix authored
This works around that ssl.wrap_socket silently skips ssl negotiation on sockets that was connected but since then has been reset by the peer but not yet closed at the Python level. That leaves the socket in a state where .getpeercert() fails with an AttributeError on None. See http://bugs.python.org/issue13721 . A call to .cipher() is now used to verify that the wrapping really did succeed. Otherwise it aborts with "ssl connection failed".
-
- Jan 08, 2012
-
-
Levi Bard authored
Refactor and remove pasted code from lfcommands.py
-
Levi Bard authored
Add tests for lfconvert codepaths where: * largefiles have been both renamed and relinked * .hgtags has invalid content
-
Levi Bard authored
Check for errors when parsing .hgtags during lfconvert, and skip lines that don't parse or refer to invalid changesets.
-
Levi Bard authored
-
- Jan 10, 2012
-
-
Matt Mackall authored
-
- Jan 08, 2012
-
-
Alexander Sauta authored
-
- Jan 07, 2012
-
-
Andrei Polushin authored
-
- Jan 05, 2012
-
-
Alexander Sauta authored
-
- Jan 04, 2012
-
-
Alexander Sauta authored
-
Alexander Sauta authored
-
- Jan 10, 2012
-
-
Matt Mackall authored
-
- Jan 08, 2012
-
-
Steven Brown authored
As of b12362ab13e7 (first released as part of Mercurial 2.0), the rebase command accepted ONLY revsets for the source and base arguments and no longer accepted old-style revision specifications. As a result, some revision names were no longer recognised, e.g. hg rebase --base br-anch abort: unknown revision 'br'! These arguments are now interpreted first as old-style revision specifications, then as revsets when no matching revision is found. This restores backwards compatibility with releases prior to 2.0.
-
- Jan 06, 2012
-
-
Pierre-Yves David authored
-
Olav Reinert authored
-
- Jan 08, 2012
-
-
Dan Villiom Podlaski Christiansen authored
Such as a copy destination; see the added test.
-
Dan Villiom Podlaski Christiansen authored
-
- Jan 07, 2012
-
-
Levi Bard authored
This tests for inappropriate locking (issue3182) by running hg status as a precommit hook.
-
Levi Bard authored
Don't lock/write on operations that should be readonly (status). Always lock when writing the lfdirstate (rollback). Don't write lfdirstate until after committing; state isn't actually changed until the commit is complete.
-
Na'Tosha Bard authored
When rebasing, we need to trust that the standins are always correct. The rebase operation updates the standins according to the changeset it is rebasing. We need to make the largefiles in the working copy match. If we don't make them match, then they get accidentally reverted, either during the rebase or during the next commit after the rebase. This worked previously only becuase we were relying on the behavior that largefiles with a changed standin, but unchanged contents, never showed up in the list of modified largefiles. Unfortunately, pre-commit hooks can get an incorrect status this way, and it also results in extra execution of code. The solution is to simply trust the standins when we are about to commit a rebased changeset, and politely ask updatelfiles() to pull the new contents down. In this case, updatelfiles() will also mark any files it has pulled down as dirty in the lfdirstate so that pre-commit hooks will get correct status output.
-
Na'Tosha Bard authored
Implementing addremove correctly in largefiles is tricky, becuase the original addremove function does not call into any of the add or remove function we've already overridden in the extension. So the trick is to implement addremove without duplicating any code. This patch implements addremove by pulling out the interesting parts of override_add() and override_remove() into generic utility functions, and using those to handle the largefiles in addremove. Then a matcher is installed that will ignore all largefiles, and the original addremove function is called to take care of the regular files in addremove. A small bit of monkey patching is used to make sure that remove_largefiles() notifies the user when a file is removed by addremove and also makes sure the removal of largefiles doesn't interfer with the original addremove's operation of removing the standin.
-
- Jan 08, 2012
-
-
Martin Geisler authored
Found by running the test suite with the -3 flag to show places where we have int / int division that can be replaced with int // int.
-
Martin Geisler authored
-
Levi Bard authored
-
Martin Geisler authored
-
Na'Tosha Bard authored
-
Na'Tosha Bard authored
This patch makes "hg remove" work the same way on largefiles as it does on regular Mercurial files. If you try to remove an added largefile, the removal fails and you are instead prompted to use "hg forget" to undo the add.
-
- Jan 07, 2012
-
-
Na'Tosha Bard authored
This comment is invalid. The hg.update() function will abort in the case of any genuine error, so there is nothing to check. If we have gotten to this point in execution, nothing critical has gone wrong, and if any standins have been updated, we must pull new largefiles.
-
Na'Tosha Bard authored
-