Mon, 17 Aug 2015 22:56:12 -0400 histedit: correct spelling etc in more comments
Augie Fackler <augie@google.com> [Mon, 17 Aug 2015 22:56:12 -0400] rev 26039
histedit: correct spelling etc in more comments Spotted during review of another patch.
Fri, 31 Jul 2015 12:54:16 -0700 histedit: add a missing "s" in a comment
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 31 Jul 2015 12:54:16 -0700] rev 26038
histedit: add a missing "s" in a comment
Fri, 14 Aug 2015 15:22:47 -0700 convert: fix convert dropping p2 contents during filemap merge
Durham Goode <durham@fb.com> [Fri, 14 Aug 2015 15:22:47 -0700] rev 26037
convert: fix convert dropping p2 contents during filemap merge When converting a merge commit using a filemap convert (i.e. when moving contents from the root of the repo into subdir1/), convert would silently drop the entire contents of the target repo's p2. This was because when it built the target commit, it did so by taking the target p1 and adding only the files that changed in the source repo's merge commit. This breaks in the case where the target repo has files that are unrelated to the source repo (like in the case where you use convert to import a repo as a subdirectory of another). The fix is to use Mercurial's merge logic to detect which files in p2 we should carry over to the merge. It follows three rules: 1) if the file belongs to the source, don't try to merge it. Rely on the list of files provided to putcommit to be correct. 2) if the file requires merging or user input (change vs deleted), throw an exception. We don't have enough info to do this. 3) if p2 has the newest, non-merge-requiring version of the file, take it I've also added a test to cover this issue.
Sat, 15 Aug 2015 13:46:30 -0700 convert: implements targetfilebelongstosource for filemap source
Durham Goode <durham@fb.com> [Sat, 15 Aug 2015 13:46:30 -0700] rev 26036
convert: implements targetfilebelongstosource for filemap source This is an implementation of the new targetfilebelongstosource() function for the filemapper. It simply checks if the given file name is prefixed by any of the rename destinations. It is not a perfect implementation since it doesn't account for the filemap specifying includes or excludes, but that makes the problem much harder, and this implementation should suffice for most cases.
Sat, 15 Aug 2015 13:44:55 -0700 convert: add function to test if file is from source
Durham Goode <durham@fb.com> [Sat, 15 Aug 2015 13:44:55 -0700] rev 26035
convert: add function to test if file is from source This adds a base implementation of a function that tests if a given file from a target repo came from the source repo. This will be used later to detect which files did not come from the source repo during a merge, so we can merge those files correctly instead of dropping them.
Sat, 15 Aug 2015 17:50:59 +0900 revsetbenchmarks: run make after update so that C extensions are built
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Aug 2015 17:50:59 +0900] rev 26034
revsetbenchmarks: run make after update so that C extensions are built
Fri, 14 Aug 2015 12:36:41 +0900 reachableroots: fix memleak of integer objects at includepath loop
Yuya Nishihara <yuya@tcha.org> [Fri, 14 Aug 2015 12:36:41 +0900] rev 26033
reachableroots: fix memleak of integer objects at includepath loop In the first visit loop, val is decref-ed correctly after PySet_Add(). Let's do the same for the includepath loop.
Fri, 14 Aug 2015 12:31:56 +0900 reachableroots: bail if integer object cannot be allocated
Yuya Nishihara <yuya@tcha.org> [Fri, 14 Aug 2015 12:31:56 +0900] rev 26032
reachableroots: bail if integer object cannot be allocated This patch also replaces Py_XDECREF() by Py_DECREF() because we known "val" and "p" are not NULL. BTW, we can eliminate some of these allocation and error handling of int objects if the internal "seen" array has more information. For example, enum { SEEN = 1, ROOT = 2, REACHABLE = 4 }; /* ... build ROOT mask from roots argument ... */ if (seen[revnum + 1] & ROOT) { /* instead of PySet_Contains(roots, val) */ >From my quick hack, it is 2x faster.
Sat, 01 Aug 2015 05:43:39 -0700 devel-warn: issue a warning when writing bookmarks without holding the wlock
Laurent Charignon <lcharignon@fb.com> [Sat, 01 Aug 2015 05:43:39 -0700] rev 26031
devel-warn: issue a warning when writing bookmarks without holding the wlock I saw an issue in an extension that we develop where we were writing bookmarks without holding the wlock. Another extension was taking a lock at the same time and wiped out the bookmarks we were about to write. This patch adds a devel-warning to urge people to fix their invalid code.
Thu, 13 Aug 2015 19:37:47 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 13 Aug 2015 19:37:47 -0500] rev 26030
merge with stable
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip