- Oct 02, 2013
-
-
Matt Mackall authored
-
- Oct 01, 2013
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 30, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, "hg summary" may fail, when there is inconsistent rebase state: for example, the root of rebase destination revisions recorded in rebase state file is already stripped manually. Mercurial earlier than 2.7 allows users to do anything other than starting new rebase, even though current rebase is not finished or aborted yet. So, such inconsistent rebase states may be left and forgotten in repositories. This patch catches RepoLookupError at restoring rebase state for summary hook, and treat such state as "broken".
-
Katsunori FUJIWARA authored
Before this patch, "rebase --abort"/"--continue" may fail, when rebase state is inconsistent: for example, the root of rebase destination revisions recorded in rebase state file is already stripped manually. Mercurial earlier than 2.7 allows users to do anything other than starting new rebase, even though current rebase is not finished or aborted yet. So, such inconsistent rebase states may be left and forgotten in repositories. This patch catches RepoLookupError at restoring rebase state for abort/continue, and treat such state as "broken".
-
Katsunori FUJIWARA authored
Mercurial earlier than 2.7 allows users to do anything other than starting new histedit, even though current histedit is not finished or aborted yet. So, unfinished (and maybe inconsistent now) histedit states may be left and forgotten in repositories. Before this patch, histedit extension shows the message below, when it detects such inconsistent state: abort: REV is not an ancestor of working directory (update to REV or descendant and run "hg histedit --continue" again) But this message is incorrect, unless old Mercurial is re-installed, because Mercurial 2.7 or later disallows users to update the working directory to another revision. This patch changes the hint message to suggest "hg histedit --abort".
-
Pierre-Yves David authored
A `unfilteredpropertycache` is a kind of `propertycache` used on `localrepo` to unsure it will always be run against unfiltered repo and stored only once. As the cached value is never stored in the repoview instance, the descriptor will always be called. Before this patch such calls always result in a call to the `__get__` method of the `propertycache` on the unfiltered repo. That was recomputing a new value on every access through a repoview. We can't prevent the repoview's `unfilteredpropertycache` to get called on every access. In that case the new code makes a standard attribute access to the property. If a value is cached it will be used. The `propertycache` test file have been augmented with test about this issue.
-
Pierre-Yves David authored
Propertycache used standard attribute assignment. In the repoview case, this assignment was forwarded to the unfiltered repo. This result in: (1) unfiltered repo got a potentially wrong cache value, (2) repoview never reused the cached value. This patch replaces the standard attribute assignment by an assignment to `objc.__dict__` which will bypass the `repoview.__setattr__`. This will not affects other `propertycache` users and it is actually closer to the semantic we need. The interaction of `propertycache` and `repoview` are now tested in a python test file.
-
- Oct 01, 2013
-
-
Wagner Bruna authored
-
Matt Mackall authored
-
- Sep 30, 2013
-
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
Before this patch, if there are multiple roots in "--outgoing" revisions, result of "histedit --outgoing" depends on the parent of the working directory. It succeeds only when the parent of the working directory is a descendant of the oldest root in "--outgoing" revisions, and fails otherwise. It seems to be ambiguous and difficult for users. This patch makes "histedit --outgoing" abort if there are multiple roots in "--outgoing" revisions always.
-
Katsunori FUJIWARA authored
Before this patch, pushing with --new-branch permits to create multiple headed branch on the destination repository. But permitting to create new branch should be different from permitting to create multiple heads on branch. This patch prevents from careless pushing multiple headed new branch, and requires --force to push such branch forcibly.
-
Pierre-Yves David authored
Since repoview in 2.5 we do not make special call to `branchmap` when stripping. We just recompute the branchmap from a lower subset that still has valid branchmap. So I'm dropping this dead code.
-
Pierre-Yves David authored
It was unused. note how it is only extended if the list is empty. So it's always empty at the end. We could try to fix that, however this would part of the code is to be removed in the next changeset as we do not run `branchmap` on truncated repo since `repoview` in 2.5.
-
Pierre-Yves David authored
The blank line was after was after the `if` condition instead of before.
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
Before this patch, if there are multiple roots in "--outgoing" revisions, result of "histedit --outgoing" depends on the parent of the working directory. It succeeds only when the parent of the working directory is a descendant of the oldest root in "--outgoing" revisions, and fails otherwise. It seems to be ambiguous and difficult for users. This patch makes "histedit --outgoing" abort if there are multiple roots in "--outgoing" revisions always.
-
- Sep 06, 2013
-
-
Alexander Plavin authored
There was an extra anonymous outer function, called immediately. It is removed in this patch.
-
- Sep 30, 2013
-
-
Siddharth Agarwal authored
getbe32 and putbe32 need to behave differently on big-endian and little-endian systems. On big-endian ones, they should be roughly equivalent to the identity function with a cast, but on little-endian ones they should reverse the order of the bytes. That is achieved by the original definition, but __builtin_bswap32 and _byteswap_ulong, as the names suggest, swap bytes around unconditionally. There was no measurable performance improvement, so there's no point adding extra complexity with even more ifdefs for endianncess.
-
Matt Mackall authored
-
Martin Schröder authored
-
Martin Schröder authored
-
- Sep 24, 2013
-
-
Wagner Bruna authored
-
- Sep 28, 2013
-
-
Kevin Bullock authored
-
- Sep 26, 2013
-
-
Pierre-Yves David authored
And makes it use the strip extension only (except for the part testing mq interaction)
-
Pierre-Yves David authored
Strip now lives in its own extension reminder: The extension is surprisingly called `strip`. The `mq` extension force the use of the strip extension when its enabled. This is both necessary for backward compatibility (people expect `mq` to comes with strip) and become some utility function used by `mq` are now in the strip extension.
-
Pierre-Yves David authored
The next patch finally move the command. No joke! (hey, this is for issue3824)
-
Pierre-Yves David authored
One more step for issue3824.
-
Pierre-Yves David authored
One more step for issue3824
-
Pierre-Yves David authored
Strip will lives in its own extension. The extension is surprisingly called `strip`. (as discussed in issue3824) The `mq` extension force the use of the strip extension when its enabled. This will both necessary for backward compatibility (people expect `mq` to comes with strip) and become some utility function used by `mq` will move in the strip extension.
-
David Soria Parra authored
-
- Sep 25, 2013
-
-
Pierre-Yves David authored
This is the last step before being able to extract `strip` in its own extension. The changes are made in mq to allow a move only extraction without touching a line of code.
-
Pierre-Yves David authored
It does not depend on `mq.queue` anymore.
-
Pierre-Yves David authored
Same as in the previous changeset, rev is never `None`. We can just copy the two relevant lines in in `queue.strip`. This help having `queue.strip` independent from `queue`. One further step toward the extraction of `strip` in an independent extension. (As discussed in issue3824).
-
Pierre-Yves David authored
In this case, rev is never `None`. We can just copy the two relevant lines in in `strip`. This help having `strip` independent from `queue` one further step toward its extraction in an independent extension. (As discussed in issue3824).
-
Pierre-Yves David authored
The function is not very complex but writing this doc helped me to check if I got everything right.
-
Pierre-Yves David authored
The strip command never use the `refresh` argument. So we can use the function we just extracted.
-
Pierre-Yves David authored
The core part of `checklocalchanges` is now mq independent. We can extract it in a standalone function to help the extraction of `strip` as discussed in issue3824. A `checklocalchanges` function stay in `mq.queue` with the part related to "refresh first" messages.
-
Pierre-Yves David authored
This function does not need any of the the `mq.queue` method or attributes. It is indirectly used by the `strip` command. We are trying to extract this command in a standalone extension as discussed in issue issue3824.
-