Wed, 30 Mar 2011 17:50:34 -0500 changegroup: refactor prune as a filter
Matt Mackall <mpm@selenic.com> [Wed, 30 Mar 2011 17:50:34 -0500] rev 13810
changegroup: refactor prune as a filter
Wed, 30 Mar 2011 17:50:27 -0500 changegroup: add first logic to send file header
Matt Mackall <mpm@selenic.com> [Wed, 30 Mar 2011 17:50:27 -0500] rev 13809
changegroup: add first logic to send file header This will allow us to later change how we filter needed file nodes
Wed, 30 Mar 2011 14:42:41 -0500 url: fix tests
Matt Mackall <mpm@selenic.com> [Wed, 30 Mar 2011 14:42:41 -0500] rev 13808
url: fix tests
Wed, 30 Mar 2011 13:34:39 -0500 url: deal with drive letters
Matt Mackall <mpm@selenic.com> [Wed, 30 Mar 2011 13:34:39 -0500] rev 13807
url: deal with drive letters
Mon, 14 Mar 2011 23:50:28 +0100 bookmarks: do not forward merged bookmark (issue1877)
David Soria Parra <dsp@php.net> [Mon, 14 Mar 2011 23:50:28 +0100] rev 13806
bookmarks: do not forward merged bookmark (issue1877)
Wed, 30 Mar 2011 13:23:24 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 30 Mar 2011 13:23:24 -0500] rev 13805
merge with stable
Mon, 28 Mar 2011 20:56:56 -0400 pull: new output message when there are multiple branches
Kevin Berridge <kevin.w.berridge@gmail.com> [Mon, 28 Mar 2011 20:56:56 -0400] rev 13804
pull: new output message when there are multiple branches Pull outputs a slightly new message when there are multiple branches and the current branch has many heads: (run 'hg heads .' to see heads, 'hg merge' to merge) This message adds the "." in hg heads to encourage you to consider only the current branch's heads.
Fri, 11 Mar 2011 20:43:12 -0500 pull: don't suggest running hg merge when new heads are on different branches
Kevin Berridge <kevin.w.berridge@gmail.com> [Fri, 11 Mar 2011 20:43:12 -0500] rev 13803
pull: don't suggest running hg merge when new heads are on different branches After a pull when new heads are added but no head is added on the current branch, the "run 'hg merge'" message can be misleading. This patch doesn't output the merge message in that scenario.
Wed, 30 Mar 2011 09:49:45 +0100 bugzilla: add modified XMLRPC mode that uses email to send bug comments.
Jim Hague <jim.hague@acm.org> [Wed, 30 Mar 2011 09:49:45 +0100] rev 13802
bugzilla: add modified XMLRPC mode that uses email to send bug comments. If Bugzilla has its email interface configured, an email can be used to update bugs. If the From: address in the email matches a valid user email, Bugzillas make the update as that user. So comments attached to a bug appear under the name of the user making the change, and the user does not receive email about the change, exactly as if they had made the change via the web interface. So add a modified XMLRPC mode that uses email to modify bugs. The format of the mails is documented in the Bugzilla email_in.pl specification. Briefly, initial non-blank lines in the message body starting '@<field> = <value> modify bug fields. A blank line signals the end of the command lines, and the rest of the message is used as bug comment. Invoke the same Mercurial user to Bugzilla user email mapping currently used in the MySQL mode. All other processing - checking the bug numbers, checking user ids, etc. continues to be done via XMLRPC.
Wed, 30 Mar 2011 09:49:45 +0100 bugzilla: add XMLRPC interface.
Jim Hague <jim.hague@acm.org> [Wed, 30 Mar 2011 09:49:45 +0100] rev 13801
bugzilla: add XMLRPC interface. Add support for access to Bugzilla via the XMLRPC interface. This requires a single username and password used to log in to Bugzilla, plus the URL of the Bugzilla installation. Commit messages are added to bugs as before, but security only permits them to be added as the username used to log in.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip