Mon, 10 Dec 2012 11:18:03 -0800 synthrepo: do not crash if a list is empty
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Dec 2012 11:18:03 -0800] rev 18047
synthrepo: do not crash if a list is empty
Tue, 27 Nov 2012 22:24:02 +0100 hgwebdir: do not show RSS and Atom links for plain directories
Angel Ezquerra <angel.ezquerra@gmail.com> [Tue, 27 Nov 2012 22:24:02 +0100] rev 18046
hgwebdir: do not show RSS and Atom links for plain directories Up until now the templates that show RSS and Atom feeds on the "repository lists" (i.e. gitweb and monoblue) showed them for all entries, including regular folders. Clicking on those "folder RSS" links would result in an error page being shown. This patch hides those links for regular folders.
Tue, 04 Dec 2012 00:37:50 +0100 hgweb: add branches RSS and Atom feeds
Angel Ezquerra <angel.ezquerra@gmail.com> [Tue, 04 Dec 2012 00:37:50 +0100] rev 18045
hgweb: add branches RSS and Atom feeds There were no RSS nor Atom feeds for the branches page. Different hgweb templates linked to different feeds on their branches page (some linked to the tags feed, some to the log feed and some to the unexisting branches feed).
Fri, 07 Dec 2012 12:03:37 -0600 push: reunite comment with the line of code it describes
Kevin Bullock <kbullock@ringworld.org> [Fri, 07 Dec 2012 12:03:37 -0600] rev 18044
push: reunite comment with the line of code it describes
Fri, 07 Dec 2012 11:30:38 -0600 bookmarks: spelling correction in docstring
Kevin Bullock <kbullock@ringworld.org> [Fri, 07 Dec 2012 11:30:38 -0600] rev 18043
bookmarks: spelling correction in docstring
Thu, 06 Dec 2012 22:07:44 -0600 merge: fix mistake in moved _checkcollision call from 5881d5b7552f
Kevin Bullock <kbullock@ringworld.org> [Thu, 06 Dec 2012 22:07:44 -0600] rev 18042
merge: fix mistake in moved _checkcollision call from 5881d5b7552f
Thu, 06 Dec 2012 16:56:44 -0600 windows: correctly pass a mode to S_IFMT in statfiles
Matt Mackall <mpm@selenic.com> [Thu, 06 Dec 2012 16:56:44 -0600] rev 18041
windows: correctly pass a mode to S_IFMT in statfiles
Wed, 05 Dec 2012 14:33:15 -0800 strip: make query to get new bookmark target cheaper
Siddharth Agarwal <sid0@fb.com> [Wed, 05 Dec 2012 14:33:15 -0800] rev 18040
strip: make query to get new bookmark target cheaper The current query to get the new bookmark target for stripped revisions involves multiple walks up the DAG, and is really expensive, taking over 2.5 seconds on a repository with over 400,000 changesets even if just one changeset is being stripped. A slightly simplified version of the current query is max(heads(::<tostrip> - <tostrip>)) We make two observations here. 1. For any set s, max(heads(s)) == max(s). That is because revision numbers define a topological order, so that the element with the highest revision number in s will not have any children in s. 2. For any set s, max(::s - s) == max(parents(s) - s). In other words, the ancestor of s with the highest revision number not in s is a parent of one of the revs in s. Why? Because if it were an ancestor but not a parent of s, it would have a descendant that would be a parent of s. This descendant would have a higher revision number, leading to a contradiction. Combining these two observations, we rewrite the revset query as max(parents(<tostrip>) - <tostrip>) The time complexity is now linear in the number of changesets being stripped. For the above repository, the query now takes 0.1 seconds when one changeset is stripped. This speeds up operations that use repair.strip, like the rebase and strip commands.
Tue, 04 Dec 2012 12:54:18 -0800 graft: explicit current node tracking
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18039
graft: explicit current node tracking This changes graft to explicitly track the progression of commits it makes, and updates it's idea of the current node based on it's last commit, rather than from the working copy parent. This should have no effect on the value of current since we were reading the working copy parent immediately after commiting to it. The motivation for this change is that a subsequent patch will break the current node and working copy relationship. Splitting this out into a separate patch will make that one more readible.
Tue, 04 Dec 2012 12:54:18 -0800 graft: move commit info building
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18038
graft: move commit info building This moves the logic for generating the commit metadata ahead of the merge operation. The only purposae of this patch is to make subsequent patches easier to read, and there should be no behavior changes.
Thu, 06 Dec 2012 16:42:15 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 06 Dec 2012 16:42:15 -0600] rev 18037
merge with stable
Tue, 04 Dec 2012 12:54:18 -0800 merge: support calculating merge actions against non-working contexts
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18036
merge: support calculating merge actions against non-working contexts This is not currently used. It is instead a pre-requisite to performing non-conflicting grafts in memory, which a subsequent patch will do.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 +30000 tip