Tue, 07 Dec 2010 22:14:43 -0600 mq: update .hgsubstate if subrepos are clean (issue2499)
Kevin Bullock <kbullock@ringworld.org> [Tue, 07 Dec 2010 22:14:43 -0600] rev 13174
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
Tue, 07 Dec 2010 22:14:43 -0600 backout f08df4d38442
Kevin Bullock <kbullock@ringworld.org> [Tue, 07 Dec 2010 22:14:43 -0600] rev 13173
backout f08df4d38442
Fri, 17 Dec 2010 13:38:15 +0100 subrepo: backout f02d7a562a21
Erik Zielke <ez@aragost.com> [Fri, 17 Dec 2010 13:38:15 +0100] rev 13172
subrepo: backout f02d7a562a21 backing out f02d7a562a21 because it introduced a bug in .hgsubstate handling.
Mon, 20 Dec 2010 12:08:56 -0600 merge with i18n
Matt Mackall <mpm@selenic.com> [Mon, 20 Dec 2010 12:08:56 -0600] rev 13171
merge with i18n
Mon, 20 Dec 2010 12:08:50 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 20 Dec 2010 12:08:50 -0600] rev 13170
merge with stable
Fri, 17 Dec 2010 10:40:26 +0100 fncachestore: copy dh directory before the manifest stable
Adrian Buehlmann <adrian@cadifra.com> [Fri, 17 Dec 2010 10:40:26 +0100] rev 13169
fncachestore: copy dh directory before the manifest Before this patch, the copy order on clone was: requires 00changelog.i store\data store\00manifest.d store\00manifest.i store\00changelog.d store\00changelog.i store\dh store\fncache Which provides a theoretical non-zero probability of a race during clone where a very early reader might see a repository with missing revlog files if it sees 00changelog.i before all files inside dh have been copied. The dh directory is similar to the data directory -- just for files with long names (which are hashed). The manifest refers to files in data *and* dh, so dh should be copied before the manifest. This patch improves the copy order to: requires 00changelog.i store\data store\dh store\fncache store\00manifest.d store\00manifest.i store\00changelog.d store\00changelog.i I'm putting fncache to before the manifest while I'm at it, since fncache provides a mechanism to enumerate all repository files without visiting the manifest revisions. fncache depends only on data and dh. Note that data must be copied first, since copying data triggers the creation of the repository write lock in the destination repo (see hg.clone).
Mon, 20 Dec 2010 12:05:50 -0600 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Mon, 20 Dec 2010 12:05:50 -0600] rev 13168
merge with i18n
Fri, 10 Dec 2010 12:51:37 +0100 i18n: merge with stable
Martin Geisler <mg@aragost.com> [Fri, 10 Dec 2010 12:51:37 +0100] rev 13167
i18n: merge with stable
Fri, 10 Dec 2010 12:48:57 +0100 i18n-da: synchronize with 5dac0d04b838 stable
Martin Geisler <mg@aragost.com> [Fri, 10 Dec 2010 12:48:57 +0100] rev 13166
i18n-da: synchronize with 5dac0d04b838
Sat, 04 Dec 2010 19:28:15 +0100 i18n-de: translated strings for the purge extension stable
Arne Babenhauserheide <arne@draketo.de> [Sat, 04 Dec 2010 19:28:15 +0100] rev 13165
i18n-de: translated strings for the purge extension
Sat, 18 Dec 2010 22:06:11 +0100 merge with stable
Mads Kiilerich <mads@kiilerich.com> [Sat, 18 Dec 2010 22:06:11 +0100] rev 13164
merge with stable
Sat, 18 Dec 2010 21:58:52 +0100 https: warn when server certificate isn't verified stable
Mads Kiilerich <mads@kiilerich.com> [Sat, 18 Dec 2010 21:58:52 +0100] rev 13163
https: warn when server certificate isn't verified Mercurial will verify HTTPS server certificates if web.cacerts is configured, but it will by default silently not verify any certificates. We now warn the user that when the certificate isn't verified she won't get the security she might expect from https: warning: localhost certificate not verified (check web.cacerts config setting) Self-signed certificates can be accepted silently by configuring web.cacerts to point to a suitable certificate file.
Mon, 13 Dec 2010 11:46:31 -0500 merge: document some internal return values.
Greg Ward <greg-hg@gerg.ca> [Mon, 13 Dec 2010 11:46:31 -0500] rev 13162
merge: document some internal return values.
Thu, 16 Dec 2010 14:50:37 -0600 check-code: catch os.path.relpath
Matt Mackall <mpm@selenic.com> [Thu, 16 Dec 2010 14:50:37 -0600] rev 13161
check-code: catch os.path.relpath
Thu, 16 Dec 2010 14:50:36 -0600 check-code: catch "except as"
Matt Mackall <mpm@selenic.com> [Thu, 16 Dec 2010 14:50:36 -0600] rev 13160
check-code: catch "except as"
Thu, 16 Dec 2010 14:50:27 -0600 tests: eliminate fast-forward merge in test-tag
Matt Mackall <mpm@selenic.com> [Thu, 16 Dec 2010 14:50:27 -0600] rev 13159
tests: eliminate fast-forward merge in test-tag
Tue, 07 Dec 2010 03:29:21 +0100 merge: fast-forward merge with descendant
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Dec 2010 03:29:21 +0100] rev 13158
merge: fast-forward merge with descendant issue2538 gives a case where a changeset is merged with its child (which is on another branch), and to my surprise the result is a real merge with two parents, not just a "fast forward" "merge" with only the child as parent. That is essentially the same as issue619. Is the existing behaviour as intended and correct? Or is the following fix correct? Some extra "created new head" pops up with this fix, but it seems to me like they could be considered correct. The old branch head has been superseeded by changes on the other branch, and when the changes on the other branch is merged back to the branch it will introduce a new head not directly related to the previous branch head. (I guess the intention with existing behaviour could be to ensure that the changesets on the branch are directly connected and that no new heads pops up on merges.)
Wed, 08 Dec 2010 22:14:18 -0600 record: teach parsepatch() about non-git style headers
Steve Borho <steve@borho.org> [Wed, 08 Dec 2010 22:14:18 -0600] rev 13157
record: teach parsepatch() about non-git style headers These changes are not useful to record itself, since it is hard coded to always generate git style diffs. But it makes parsepatch() more generally useful for parsing normal patch files.
Mon, 13 Dec 2010 10:30:15 -0500 template: add showbranch template for {branch}
Eric Eisner <ede@mit.edu> [Mon, 13 Dec 2010 10:30:15 -0500] rev 13156
template: add showbranch template for {branch} Like showbranches, but always yields exactly one branch. Replaces the less correct {branches|nonempty}.
Mon, 29 Nov 2010 09:37:23 +0100 subrepo: avoids empty commit when .hgsubstate is dirty (issue2403)
Erik Zielke <ez@aragost.com> [Mon, 29 Nov 2010 09:37:23 +0100] rev 13155
subrepo: avoids empty commit when .hgsubstate is dirty (issue2403) This patch avoids empty commit when .hgsubstate is dirty. Empty commit was caused by .hgsubstate being updated back to the state of the working copy parent when committing, if a user had changed it manually and not made any changes in subrepositories. The subrepository state from the working copies parent is compared with the state calculated as a result of trying to commit the subrepositories. If the two states are the same, then return None otherwise the commit is just done. The line: "committing subrepository x" will be written if there is nothing committed, but .hgsubstate is dirty for x subrepository.
Thu, 16 Dec 2010 07:45:22 -0600 progress: don't compute estimate without a total
Augie Fackler <durin42@gmail.com> [Thu, 16 Dec 2010 07:45:22 -0600] rev 13154
progress: don't compute estimate without a total Without this, computing an estimate crashes. Test included.
Tue, 14 Dec 2010 21:58:13 -0500 subrepo: use low-level git-diff-index for dirty()
Eric Eisner <ede@mit.edu> [Tue, 14 Dec 2010 21:58:13 -0500] rev 13153
subrepo: use low-level git-diff-index for dirty() Despite its name, git-diff-index compares a revision to the files in the working directory. This seems way less sketchy and more future proof than parsing human-readable git-status.
Tue, 14 Dec 2010 21:56:43 -0500 subrepo: defer determination of git's current branch
Eric Eisner <ede@mit.edu> [Tue, 14 Dec 2010 21:56:43 -0500] rev 13152
subrepo: defer determination of git's current branch
Tue, 14 Dec 2010 21:56:43 -0500 subrepo: incorporate tracking branches into gitbranchmap
Eric Eisner <ede@mit.edu> [Tue, 14 Dec 2010 21:56:43 -0500] rev 13151
subrepo: incorporate tracking branches into gitbranchmap
Tue, 14 Dec 2010 21:53:40 -0500 subrepo: use low-level git-for-each-ref command in branchmap
Eric Eisner <ede@mit.edu> [Tue, 14 Dec 2010 21:53:40 -0500] rev 13150
subrepo: use low-level git-for-each-ref command in branchmap This command's output doesn't change across versions, and it also disambiguates cases where there are slashes in local branch names.
Wed, 15 Dec 2010 10:55:14 -0600 progress using tests: disable time estimates to avoid flakiness
Augie Fackler <durin42@gmail.com> [Wed, 15 Dec 2010 10:55:14 -0600] rev 13149
progress using tests: disable time estimates to avoid flakiness
Wed, 15 Dec 2010 10:22:54 -0600 progress: include time estimate as part of the default progress format
Augie Fackler <durin42@gmail.com> [Wed, 15 Dec 2010 10:22:54 -0600] rev 13148
progress: include time estimate as part of the default progress format
Wed, 15 Dec 2010 10:22:06 -0600 progress: only show time estimate when progress format contains 'estimate'
Augie Fackler <durin42@gmail.com> [Wed, 15 Dec 2010 10:22:06 -0600] rev 13147
progress: only show time estimate when progress format contains 'estimate'
Wed, 15 Dec 2010 10:20:36 -0600 progress: fix adding format elements after the progress bar
Augie Fackler <durin42@gmail.com> [Wed, 15 Dec 2010 10:20:36 -0600] rev 13146
progress: fix adding format elements after the progress bar Prior to this change, format elements after the progress bar would show up in the wrong order.
Wed, 15 Dec 2010 11:20:32 -0600 test-progress: test completion estimates and progress bar delay
Augie Fackler <durin42@gmail.com> [Wed, 15 Dec 2010 11:20:32 -0600] rev 13145
test-progress: test completion estimates and progress bar delay
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 +30000 tip