- Oct 08, 2012
-
-
Idan Kamara authored
-
- Oct 03, 2012
-
-
Idan Kamara authored
Heredocs are usually fed to other commands and shouldn't follow the standard conventions of shell commands. This restores the old behaviour of how heredocs were handled in old-style test files.
-
- Sep 19, 2012
-
-
Adrian Buehlmann authored
testing the store path encoding with real files
-
- Oct 02, 2012
-
-
Matt Mackall authored
suggested by Peter Hull
-
- Sep 30, 2012
-
-
Adrian Buehlmann authored
If the input path is already longer than _maxstorepathlen, then we can skip doing the basic encoding (encodedir, _encodefname and _auxencode) and directly proceed to the hashed encoding. Those encodings, if at all, will make the path only longer.
-
Adrian Buehlmann authored
Calling basicencode may make the path longer, never shorter. If it's already too long before, then we don't even need to basicencode it.
-
Adrian Buehlmann authored
-
Adrian Buehlmann authored
due to the fact that we only get to encode files ending in .i and .d inside the store
-
- Oct 01, 2012
-
-
Patrick Mézard authored
-
- Sep 26, 2012
-
-
Pierre-Yves David authored
There is multiple conflict during this test. This add a small comment that highligh the reason of a particular failure.
-
- Sep 24, 2012
-
-
Pierre-Yves David authored
This helps to check the validity of fold result and debug potential issue.
-
- Oct 01, 2012
-
-
David Soria Parra authored
-
- Sep 29, 2012
-
-
Juan Pablo Carbajal (desktop) authored
-
Matt Mackall authored
-
- Sep 27, 2012
-
-
Tomasz Kleczek authored
Suppose the following scenario: 1. Process A takes the lock (e.g. on commit). 2. Process B wants to grab the lock. Since lock file exists the exception is raised. In the catch block the testlock function is called. 3. Process A releases the lock. 4. Process B tries to read the lock file as a part of testlock function. This results in OSError (ENOENT) and since we're not inside the exception handler function this is propagated and aborts the whole operation. To fix this we now check in testlock function whether lock file actually exists and if not (i.e. if readlock fails) we just return.
-
- Sep 29, 2012
-
-
Matt Mackall authored
-
Juan Pablo Carbajal (desktop) authored
-
Patrick Mézard authored
-
Patrick Mézard authored
For some reason, find utility seems to preserve the trailing slash and append a new one on OSX: $ find somedir/ somedir/ somedir//somefile
-
- Sep 20, 2012
-
-
Pierre-Yves David authored
This changeset allows changelog object to be "filtered". You can assign a set of revision numbers to the `changelog.filteredrevs` attributes. The changelog will then pretends these revision does not exists in this repo. A few methods need to be altered to achieve this behavior: - tip - __iter_ - irevs - hasnode - headrevs For consistency and to help debugging, the following methods are altered too. Tests tend to show it's not necessary to alter them but have them raise proper exception helps to detect bad acces to filtered revisions. - rev - node - linkrev - parentrevs - flags The following methods would also need alteration for consistency purpose but this is non-trivial and not done yet. - nodemap - strip The C version of headrevs is not run if there is any revision to filter. It'll need a proper rewrite later to restore performance.
-
- Sep 03, 2012
-
-
Pierre-Yves David authored
Revision "0" and "-1" may be filtered, we can't use them in any default revrange.
-
- Sep 20, 2012
-
-
Pierre-Yves David authored
If we want to apply filtering at changelog level, we need to iterate over it. See previous changeset description for details.
-
- Sep 03, 2012
-
-
Pierre-Yves David authored
Make the pure python implementation of headrevs available to derived classes. It is important because filtering logic applied by `revlog` derived class won't have effect on `index`. We want to be able to bypass this C call to implement our own.
-
Pierre-Yves David authored
This prepares changelog level filtering. We can't assume that any revision can be heads because filtered revisions need to be excluded. New algorithm: - All revisions now start as "non heads", - every revision we iterate over is made candidate head, - parents of iterated revisions are definitely not head. Filtered revisions are never iterated over and never considered as candidate head.
-
- Sep 20, 2012
-
-
Pierre-Yves David authored
This prepares changelog level filtering. We need the algorithms used in revlog to work on a subset of revisions. To achieve this, the use of explicit range of revision is banned. `range` and `xrange` calls are replaced by a `revlog.irevs` method. Filtered super class can then overwrite the `irevs` method to filter out revision.
-
- Sep 03, 2012
-
-
Pierre-Yves David authored
We can only use copy clone if the cloned repo do not have any secret changeset. The current method for that is to run the "secret()" revset on the remote repo. But with proper filtering of hidden or unserved revision by the remote this revset won't return any revision even if some exist remotely. This changeset adds an explicit function to know if a repo have any secret revision or not. The other option would be to disable filtering for the query but I prefer the approach above, lighter both regarding code and performance.
-
Pierre-Yves David authored
The forced recomputation of the branch cache was introduced by `ee317dbfb9d0`. Back there, `addchangegroup` did not handle any lock logic. Later `ee1ed6afac21` introduced lock logic to `addchangegroup`. Its description does not explain why the `updatebranchcache` call is made outside locking. I believe that the lock was released there because it fit well with the transaction release already in the code. Finally `926a06f7a353` moved all "unlocked" code of `addchangegroup` to an `repo._afterlock` callback. I do not think that the call to `updatebranchcache()` requires to be done outside locking. That may even be a bad idea to do so. Bringing this call back in the `addchangegroup` function makes the flow simpler and eases the following up changelog level filtering business.
-
- Aug 02, 2012
-
-
durin42 authored
This makes it possible to do lock validation as part of a normal test run. I didn't attempt any wlock validation because that's a bit more subtle to detect properly. Thanks to the initial patch from Mads for the idea.
-
- Sep 25, 2012
-
-
Sergey Kishchenko authored
At the moment the resolve command doesn't save progress during the resolve process. In example if you try to resolve 100 conflicting files and interrupt the process (e.g., you close the external merge tool) after resolving 50 files you'll end up with 100 unresolved conflicts. Saving the progress helps a lot with long going merges. It's easy to achieve same behavior with simple script that calls resolve command for each unresolved file but it makes sense to make such behavior a default
-
- Sep 22, 2012
-
-
Katsunori FUJIWARA authored
Before this patch, the argument bound to the source repository of incoming bookmarks for "bookmarks.diff()" is named as "remote". But in "hg outgoing" case, this argument is bound to local repository object. In addition to it, "local"/"remote" seem to mean not the direction of propagation of bookmarks, but just the location of cooperative repositories. To indicate the direction of propagation of bookmarks clearly on the source code, this patch uses "d(st)" and "s(rc)" combination instead of "l(ocal)" and "r(emote)" one. - "repo" and "remote" arguments are renamed to "dst" and "src" - "lmarks" and "rmarks" variables are renamed to "dmarsk" and "smarks"
-
- Sep 27, 2012
-
-
Pierre-Yves David authored
When histedit "continue", there is several complicated logic to apply in order to detect intermediate changeset and concluded pending operation. This changeset extract this logic in a dedicated function to lighten the main one. No alteration to the logic is done.
-
- Sep 26, 2012
-
-
Pierre-Yves David authored
I expected `tip` to be repo's tip when it was the rewritten set tip. I rename the variable to the less ambiguous `topmost`.
-
Pierre-Yves David authored
Create a function dedicated to stripping a group of node. All existing duplicated code is replaced by call to this function. This new function take care of stripping known and relevant node only.
-
Pierre-Yves David authored
This lighten the main function and will help to see future changes to this bookmark logic.
-
Pierre-Yves David authored
- `node.hex(n)[:12]` is the same as `node.short(n)` - `ctx.hex()[:12]` is the same as `str(ctx)`
-
- Sep 27, 2012
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jul 31, 2012
-
-
Matt Harbison authored
Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A' would add all files (including the previously added large files) as normal files. Only after a commit where a file was added with --large would subsequent adds or 'ci -A' take into account the minsize or the pattern configuration. This change more closely follows the help for largefiles, which mentions that 'add --large' is required to enable the configuration, but doesn't mention the previously required commit. Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before a largefile enabling commit), the forget command would error out saying '.hglf/<file> not tracked'. This is also fixed. This reports that a repo is largefiles enabled as soon as a file is added with --large, which enables 'add', 'addremove' and 'ci -A' to honor the config settings before the first commit. Note that prior to the next commit, if all largefiles are forgotten, the repository goes back to reporting the repo as not largefiles enabled. It makes no sense to handle this by adding a --large option to 'addremove', because then it would also be needed for 'commit', but only when '-A' is specified. While this gets around the awkwardness of having to add a largefile, then commit it, and then addremove the other files when importing an existing codebase (and preserving that extra commit in permanent history), it does still require finding and manually adding one of the files as --large. Therefore it is probably desirable to have a --large option for init as well.
-
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 25, 2012
-
-
Alexander Sauta authored
-