- Jan 18, 2015
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Wagner Bruna authored
-
Matt Mackall authored
As spotted by Malte Helmert.
-
Matt Mackall authored
-
- Jan 17, 2015
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
They're not meaningful or portable
-
Matt Mackall authored
It's not meaningful or portable
-
Matt Mackall authored
Buildbot pointed out that this test wasn't passing on Linux+vfat because there's no chmod for shell scripts.
-
Matt Mackall authored
-
Solomon Matthews authored
-
Solomon Matthews authored
-
Solomon Matthews authored
-
- Jan 16, 2015
-
-
Solomon Matthews authored
No change in behavior.
-
- Jan 17, 2015
-
-
Pierre-Yves David authored
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 authored
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.
-
Pierre-Yves David authored
This empty string key is used for the store. This will be needed to properly rollback backup in a future changesets.
-
- Jan 16, 2015
-
-
Pierre-Yves David authored
The argument is a string containing the journal name (used as prefix for all other transaction file). This is not the transaction file itself. So we clarify this.
-
- Jan 05, 2015
-
-
Pierre-Yves David authored
Using 'copyfile' (single file) instead of 'copyfiles' (tree) will ensures destination file will be overwritten. This will prevent some abort if backup file are left in place for random reason. It also seems more correct.
-
Pierre-Yves David authored
Some code paths use 'copyfiles' (full tree) for a single file to take advantage of the best-effort-hard-linking parameter. We add similar parameter and logic to 'copyfile' (single file) for this purpose. The single file version have the advantage to overwrite the destination file if it exists.
-
- Jan 16, 2015
-
-
Eric Sumner authored
This adds an experimental option 'strip-bundle2-version' which causes backup bundles to use bundle2 formatting. Especially for generaldelta repositories, this should provide significant performance gains for any operation that needs to write a backup.
-
- Jan 15, 2015
-
-
Eric Sumner authored
Allow a version parameter to specify which version of the packer should be used
-
Eric Sumner authored
This diff adds support to writebundle to generate a bundle2 wrapper; upcoming diffs will add an option to write a v2 changegroup part instead of v1 in these bundles.
-
Eric Sumner authored
The next diff will add support for writing bundle2 files to writebundle, but the bundle2 generator wants access to a ui object. This changes the signature and callsites to pass one in.
-
- Jan 17, 2015
-
-
Matt Mackall authored
-
- Jan 09, 2015
-
-
Mads Kiilerich authored
Standins are read before and after an update/merge, and all the standins that changes are handed to updatelfiles for getting their corresponding largefiles updated. updatelfiles would then hash the largefile and see if it already matched the new expected hash. If so, it would skip the update. If different, the largefile would be updated. It would happen very rarely that the largefile happened to match the new hash (and thus not the old one) and the hashing would thus be pointless ... and hashing is not cheap. Instead, when it is known that the standin hash changed (from an update), just update the standin unconditionally. If the largefile was "unsure" before the update, it was hashed at that point, so we know there is nothing to preserve. (Also, the hashing in updatelfiles was not used to preserve changes, but only to be lazy about updating the largefile, so nothing is lost by not doing this extra hashing.) There might be rare situations where we now will update largefiles that didn't have to be updated, but in all relevant cases (?) this will improve performance. Updates on a repo with some big largefiles has been seen to go from 9.19 s to 6.8 s - that is 26% less painful.
-
- Jan 16, 2015
-
-
Mads Kiilerich authored
This checking can take a huge amount of time and we should give user a hint that something is going on.
-
- Jan 15, 2015
-
-
Eric Sumner authored
This adds support for bundle2 files to the unbundle command.
-
- Jan 16, 2015
-
-
Eric Sumner authored
This will also be used for 'hg unbundle'
-
durin42 authored
This will help us not regress this case in the future.
-
- Jan 15, 2015
-
-
Eric Sumner authored
This enables debugbundle to print supporting info for bundle2 files.
-
- Jan 13, 2015
-
-
Matt Harbison authored
This was a remnant of the code prior to overridding cmdutil.add().
-
Matt Harbison authored
The --large, --normal and --lfsize args couldn't be passed to a subrepo before, and files in the subrepos would be added silently (if -v wasn't specified) as normal files. As an added bonus, 'hg add --dry-run' no longer prints that largefiles would also be added as normal files as well.
-
Matt Harbison authored
The largefiles extensions needs to be able to pass --large, --normal and --lfsize to subrepos via cmdutil.add() and hgsubrepo.add(). Rather than add additional special purpose arguments, stop extracting the existing args from the **opts passed to commands.add() and just pass them along.
-
- Dec 31, 2014
-
-
Matt Harbison authored
The arguments will need to stay present when making add work with subrepos.
-
- Jan 11, 2015
-
-
Angel Ezquerra authored
cd79fb4d75fd introduced a way to share bookmarks. When a repository share that shares bookmarks was created, a .hg/bookmarks.shared file was created to mark the repository share as one that shares its bookmarks. We have plans to introduce other levels of sharing, including a "full share" mode. Rather than creating a new ".shared" file for each new thing that we may want to share It seems better to create a single "shared" file that will list what is shared for a given shared repository. This should make it much easier to get a list of everything that is shared by a given shared repository. The shared file contains a list of shared "items" (such as bookmarks). Each shared "item" is added as a new line in the file. For now the only possible entry in the file is "bookmarks".
-
- Nov 02, 2014
-
-
Mads Kiilerich authored
-
- Jan 16, 2015
-
-
Mads Kiilerich authored
Use the new and more TLS support in Python 2.7.9.
-