Mon, 05 Oct 2015 00:18:11 -0700 bundlerepo: indent some code to prepare next patch
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:18:11 -0700] rev 26543
bundlerepo: indent some code to prepare next patch We are about to add a new condition. Code is indented in a separated patch for readability.
Thu, 08 Oct 2015 01:40:21 -0700 bundle2: add a way to just forward the bundle2 stream to another user
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 01:40:21 -0700] rev 26542
bundle2: add a way to just forward the bundle2 stream to another user There is use case for directly forward and bundle2 stream from the peer to a file (eg: 'hg incoming --bundle'), However ssh peers have no way to know the 'getbundle' is over except for actually interpreting the bundle. So we need to have the unbundle do the interpreting and forward job. The function is marked as private to highlight that this is terrible and that we are sorry.
Mon, 05 Oct 2015 01:10:49 -0700 bundle2: split parameter retrieval and processing
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 01:10:49 -0700] rev 26541
bundle2: split parameter retrieval and processing We want to introduce a simple way to forward the content of a bundle2 stream. For this purpose, we will need to both yield the parameters block and process it (to apply any behavior change it might indicate).
Mon, 05 Oct 2015 00:14:47 -0700 changegroup: extract the file management part in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:14:47 -0700] rev 26540
changegroup: extract the file management part in its own function The current writebundle function do two things: - taking a changegroup-packer instance and storing it into a valid bundle with proper header. - creating a temporary or requested file to store that bundle We would like to make it easier to forward bundle stream directly from a remote peer to a file, so we split the two logic to be able to skip the one about building a valid bundle (the remote is already sending one).
Sun, 04 Oct 2015 21:48:19 -0700 unbundle: properly read head modification result from bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 04 Oct 2015 21:48:19 -0700] rev 26539
unbundle: properly read head modification result from bundle2 We were reading the wrong key...
Wed, 07 Oct 2015 23:04:31 +0900 revset: strip off "literal:" prefix from bookmark not found error
Yuya Nishihara <yuya@tcha.org> [Wed, 07 Oct 2015 23:04:31 +0900] rev 26538
revset: strip off "literal:" prefix from bookmark not found error This is what branch() and tag() do.
Wed, 07 Oct 2015 23:00:29 +0900 revset: do not fall through to revspec for literal: branch (issue4838)
Yuya Nishihara <yuya@tcha.org> [Wed, 07 Oct 2015 23:00:29 +0900] rev 26537
revset: do not fall through to revspec for literal: branch (issue4838) If "literal:" is specified, it must not be a revset expression. It should error out with a better message.
Wed, 07 Oct 2015 21:08:14 +0100 hgweb: ensure both foreground and background colors are specified (issue4872)
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Wed, 07 Oct 2015 21:08:14 +0100] rev 26536
hgweb: ensure both foreground and background colors are specified (issue4872) When users configure the default foreground or background color to non-default (black on white) values, several hgweb styles lack contrast for headers and table row items. This patch fixes that by ensuring that where either foreground or background colors are specified, both are specified.
Thu, 08 Oct 2015 23:24:38 +0900 templater: do not pre-evaluate generator keyword at runsymbol (issue4868) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Oct 2015 23:24:38 +0900] rev 26535
templater: do not pre-evaluate generator keyword at runsymbol (issue4868) It was introduced by e06e9fd2d99f, but the important code was removed by a3c2d9211294. So there was no positive effect other than exhausting memory. The problem spotted by e06e9fd2d99f is that you can't use a generator keyword more than once. For example, in hgweb template, "{child} {child}" doesn't work because the first "{child}" consumes the generator. But as a3c2d9211294 says, the fix was wrong because it could overwrite a callable keyword that returns a generator. Also the fix didn't work for a generator of generator such as "{diff}" keyword. So, the proper fix for that problem would be to not put a generator in a keyword table. Instead, it should be a factory of a generator. Note that this should fix the memory issue in hgweb, but my firefox killed by OOM in place. Be careful to not use a modern web browser to test the issue4868.
Mon, 05 Oct 2015 01:47:33 -0700 merge: drop special parent assignment in the obsolete case
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 01:47:33 -0700] rev 26534
merge: drop special parent assignment in the obsolete case We can safely drop this because the very same assignment is enforcement later in the function. Dropping it will make it simpler to extract the default destination logic in its own function.
Thu, 01 Oct 2015 20:31:43 -0700 bundle: use bundle2 if repository uses general delta
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 20:31:43 -0700] rev 26533
bundle: use bundle2 if repository uses general delta As bundle1 does not support generaldelta, this would mean recomputing delta at bundle time. This is similar to what we do for strip and shelve and was tracked as issue4865.
Thu, 01 Oct 2015 20:21:16 -0700 parsebundletype: add a comment for future generation
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 20:21:16 -0700] rev 26532
parsebundletype: add a comment for future generation
Thu, 01 Oct 2015 19:16:00 -0700 bundle: extend the format of --type to support version and compression
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 19:16:00 -0700] rev 26531
bundle: extend the format of --type to support version and compression We had some basic undocumented support for uncompressed bundle2 support. We now have an official extensible syntax to specify both format type and compression (eg: bzip2-v2). In practice, this changeset introduce the 'v1' and 'v2' identifier to make it possible to combine format and compression. The default format is still 'v1'. We'll care about picking 'v1' or 'v2' in regard with general delta in the next changesets.
Wed, 07 Oct 2015 20:19:20 +0100 hgweb: fix border-radius for standards-based browsers
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Wed, 07 Oct 2015 20:19:20 +0100] rev 26530
hgweb: fix border-radius for standards-based browsers While here, remove an old gecko-specific property, as gecko has supported the unprefixed version for many years.
Wed, 07 Oct 2015 21:28:43 -0700 filemerge: move precheck to before files are written out
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:28:43 -0700] rev 26529
filemerge: move precheck to before files are written out This is much simpler, and also avoids unnecessary disk IO.
Wed, 07 Oct 2015 22:58:52 -0700 filemerge: move 'merging' output to before file creation
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 22:58:52 -0700] rev 26528
filemerge: move 'merging' output to before file creation This has no visible impact but makes some future work simpler.
Wed, 07 Oct 2015 21:21:56 -0700 filemerge.filemerge: make a tuple containing merge paths on disk
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:21:56 -0700] rev 26527
filemerge.filemerge: make a tuple containing merge paths on disk We're going to need this same tuple elsewhere.
Wed, 07 Oct 2015 16:14:57 -0700 filemerge: switch trymerge boolean to mergetype enum
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 16:14:57 -0700] rev 26526
filemerge: switch trymerge boolean to mergetype enum trymerge = False becomes mergetype = nomerge, and trymerge = True becomes mergetype = fullmerge or mergeonly, depending on whether a premerge happens.
Wed, 07 Oct 2015 15:13:41 -0700 filemerge: add some merge types
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 15:13:41 -0700] rev 26525
filemerge: add some merge types We're going to turn the 'trymerge' boolean into a 'mergetype' enum with these three possible values.
Thu, 08 Oct 2015 01:41:30 +0900 shelve: restore unshelved dirstate explicitly after aborting transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26524
shelve: restore unshelved dirstate explicitly after aborting transaction Before this patch, "hg unshelve" uses aborting a current transaction to discard temporary changes while unshelving. This assumes that dirstate changes in a transaction scope are kept even after aborting it. But this assumption will be broken by "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch explicitly saves shelved dirstate just before aborting current transaction, and restore dirstate with it after aborting by utility function '_aborttransaction()' added by previous patch.
Thu, 08 Oct 2015 01:41:30 +0900 shelve: restore shelved dirstate explicitly after aborting transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26523
shelve: restore shelved dirstate explicitly after aborting transaction Before this patch, "hg shelve" uses aborting a current transaction to discard temporary changes while shelving. This assumes that dirstate changes in a transaction scope are kept even after aborting it. But this assumption will be broken by "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch explicitly saves shelved dirstate just before aborting current transaction, and restore dirstate with it after aborting by utility function '_aborttransaction()' added by previous patch. This patch replaces 'if tr: tr.abort()' by 'lockmod.release(tr)', because the former is already done in '_aborttransaction()' (and the latter has no effect), if current transaction is aborted in it successfully. Otherwise, the latter is enough to trigger aborting.
Thu, 08 Oct 2015 01:41:30 +0900 shelve: add utility to abort current transaction but keep dirstate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26522
shelve: add utility to abort current transaction but keep dirstate "hg shelve" and "hg unshelve" use aborting a current transaction to discard temporary changes while (un)shelving. This assumes that dirstate changes in a transaction scope are kept even after aborting it. But this assumption will be broken by "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch adds utility function "_aborttransaction()" to abort current transaction but keep dirstate changes for (un)shelving. 'dirstate.invalidate()' just after aborting a transaction should be removed soon by subsequent patch, which writes or discards in-memory dirstate changes at releasing transaction according to the result of it. BTW, there are some other ways below, which (seem to, at first glance) resolve this issue. But this patch chose straightforward way for ease of review and future refactorring. - commit transaction at first, and then rollback it It causes unintentional "dirty read" of running transaction to other processes at committing it. - use dirstateguard to save and restore shelved dirstate After DirstateTransactionPlan, making 'dirstate.write()' write in-memory changes into actual file requires 'transaction.writepending()' while transaction running. It causes meaningless writing other in-memory changes out, even though they are never referred. In addition to it, it isn't desirable that scope of dirstateguard and transaction intersects each other. - get list of files changed from the parent, keep it in memory, and emulate that changes after aborting transaction This additional memory consumption may block aborting transaction in large repository (on small resource environment).
Thu, 08 Oct 2015 01:41:30 +0900 dirstate: split write to write changes into files other than .hg/dirstate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26521
dirstate: split write to write changes into files other than .hg/dirstate '_writedirstate()' is used mainly for "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan
Thu, 08 Oct 2015 01:41:30 +0900 bookmarks: use recordchange instead of writing if transaction is active
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26520
bookmarks: use recordchange instead of writing if transaction is active Before this patch, 'bmstore.write()' always write in-memory bookmark changes into '.hg/bookmarks' regardless of transaction activity. If 'bmstore.write()' is invoked inside a transaction and it writes changes into '.hg/bookmarks', then: - original bookmarks aren't restored at failure of that transaction This breaks "all or nothing" policy of the transaction. BTW, "hg rollback" can restore bookmarks successfully even before this patch, because original bookmarks are saved into '.hg/journal.bookmarks' at the beginning of the transaction, and it (actually renamed as '.hg/undo.bookmarks') is used by "hg rollback". - uncommitted bookmark changes are visible to other processes This is a kind of "dirty read" For example, 'rebase.rebase()' implies 'bmstore.write()', and it may be executed inside the transaction of "hg unshelve". Then, intentional aborting at the end of "hg unshelve" transaction doesn't restore original bookmarks (this is obviously a bug). This patch uses 'bmstore.recordchange()' instead of actual writing by 'bmstore._writerepo()', if any transaction is active This patch also removes meaningless restoring bmstore explicitly at the end of "hg shelve". This patch doesn't choose fixing each 'bmstore.write()' callers as like below, because writing similar code here and there is very redundant. before: bmstore.write() after: tr = repo.currenttransaction() if tr: bmstore.recordchange(tr) else: bmstore.write() Even though 'bmstore.write()' itself may have to be discarded by putting bookmark operations into transaction scope, this patch chose fixing it to implement "transactional dirstate" at first.
Wed, 07 Oct 2015 00:27:23 -0700 filemerge: run symlink check for :merge3
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 00:27:23 -0700] rev 26519
filemerge: run symlink check for :merge3 Just like :merge, :merge3 doesn't support merging symlinks.
Wed, 07 Oct 2015 00:24:44 -0700 filemerge: print correct name of tool for symlink checks
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 00:24:44 -0700] rev 26518
filemerge: print correct name of tool for symlink checks Earlier we'd print ':merge' even if the tool was something else like ':union'. That's clearly a bug.
Wed, 07 Oct 2015 00:01:16 -0700 filemerge: normalize 'internal:foo' names to ':foo'
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 00:01:16 -0700] rev 26517
filemerge: normalize 'internal:foo' names to ':foo' In upcoming patches we're going to present these names in the UI -- it would be good not to present deprecated names.
Tue, 06 Oct 2015 22:57:21 -0700 filemerge: use symlinkcheck for :merge and :union
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 22:57:21 -0700] rev 26516
filemerge: use symlinkcheck for :merge and :union This exposes a couple of bugs, both of which will be fixed in upcoming patches.
Tue, 06 Oct 2015 22:56:33 -0700 filemerge: add a precheck for symlinks
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 22:56:33 -0700] rev 26515
filemerge: add a precheck for symlinks This will be used by internal merge tools.
Tue, 06 Oct 2015 22:55:21 -0700 filemerge: call precheck if available
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 22:55:21 -0700] rev 26514
filemerge: call precheck if available In upcoming patches we'll define a precheck function for some merge tools.
Tue, 06 Oct 2015 22:54:14 -0700 filemerge: add a before-merge callback to internal merge tools
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 22:54:14 -0700] rev 26513
filemerge: add a before-merge callback to internal merge tools We're going to separate the pre-merge and merge steps for merge tools. The merge step will be specific to the tool, but the pre-merge step will be common to all merge tools that need it. However, some merge tools run checks *before* the pre-merge step. This callback will allow that to continue to work.
Tue, 06 Oct 2015 17:39:13 -0700 filemerge: indent filemerge.filemerge
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 17:39:13 -0700] rev 26512
filemerge: indent filemerge.filemerge This will make upcoming patches much easier to review.
Thu, 01 Oct 2015 20:15:00 -0700 test-bundle-type: replace unbundle with debugbundle
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 20:15:00 -0700] rev 26511
test-bundle-type: replace unbundle with debugbundle We now have a convenient command to look at bundle contents, let's use it.
Thu, 01 Oct 2015 18:01:24 -0700 bundle: extract the parsing of the bundle type in a function
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 18:01:24 -0700] rev 26510
bundle: extract the parsing of the bundle type in a function We are going to introduce significant extensions of the bundle parsing code to support creation of bundle2 through the bundle command. As an early step, we extract the logic in its own function.
Thu, 01 Oct 2015 19:14:47 -0700 changegroup: add version argument to getchangegroup
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 19:14:47 -0700] rev 26509
changegroup: add version argument to getchangegroup For some obscure reasons (probably upsetting a Greek goddess), getchangegroup did not had a 'version' argument to control the changegroup version. We fixes this to allow cg02 to be used with 'hg bundle' in the future.
Thu, 01 Oct 2015 19:14:33 -0700 changegroup: add version argument to getlocalchangegroup
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 19:14:33 -0700] rev 26508
changegroup: add version argument to getlocalchangegroup For some obscure reasons (probably upsetting a Greek goddess), getlocalchangegroup did not have a 'version' argument to control the changegroup version. We fix this to allow cg02 to be used with 'hg bundle' in the future.
Thu, 01 Oct 2015 15:08:00 -0700 shelve: bundle using bundle2 if repository is general delta (issue4862)
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 15:08:00 -0700] rev 26507
shelve: bundle using bundle2 if repository is general delta (issue4862) This will prevent expensive delta computation on bundling and is similar to what we do for strip backup.
Thu, 01 Oct 2015 15:09:32 -0700 shelve: move changegroup generation inside writebundle
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 15:09:32 -0700] rev 26506
shelve: move changegroup generation inside writebundle We will generate different changegroup if general delta is enabled so we gather this in the lower level function. There wasn't any good reason to have it in the main code anyway.
Tue, 29 Sep 2015 17:14:30 -0700 shelve: compress on-disk bundle
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 29 Sep 2015 17:14:30 -0700] rev 26505
shelve: compress on-disk bundle Shelve is using 'HG10UN' bundle for no obvious reason. Changing this to 'HG10BZ' as we do for other bundle stored on disk.
Wed, 07 Oct 2015 13:44:48 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 07 Oct 2015 13:44:48 -0500] rev 26504
merge with stable
Mon, 05 Oct 2015 10:43:16 -0600 notify: fix fromauthor setting for 'incoming' hook type (issue4194) stable
Bruce Cran <bruce.cran@gmail.com> [Mon, 05 Oct 2015 10:43:16 -0600] rev 26503
notify: fix fromauthor setting for 'incoming' hook type (issue4194) Set the author field in notification emails for the 'incoming' hook type in addition to 'changegroup' and 'outgoing' types.
Mon, 05 Oct 2015 12:37:26 -0400 templater: protect word() from crashing on out of range negative value stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 05 Oct 2015 12:37:26 -0400] rev 26502
templater: protect word() from crashing on out of range negative value The function isn't documented to work with negative values at all, but it does, which can be useful. However, the range check didn't account for this.
Fri, 02 Oct 2015 13:00:47 -0700 commands: add a new debug command to print merge state
Siddharth Agarwal <sid0@fb.com> [Fri, 02 Oct 2015 13:00:47 -0700] rev 26501
commands: add a new debug command to print merge state We're going to be extending the merge state very soon, and this will give us a way to test all that.
Wed, 30 Sep 2015 21:22:31 -0700 merge.mergestate: factor out code to validate v1/v2 records
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 21:22:31 -0700] rev 26500
merge.mergestate: factor out code to validate v1/v2 records We're going to need this in another place in upcoming patches.
Tue, 06 Oct 2015 13:19:05 -0700 localrepo: prevent wlock from being inherited when a transaction is running
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 13:19:05 -0700] rev 26499
localrepo: prevent wlock from being inherited when a transaction is running Review feedback from Pierre-Yves David. A separate line of work is working to ensure that dirstate writes are written to a separate 'pending' file while a transaction is active. Lock inheritance currently conflicts with that, so dodge the issue by simply preventing inheritance while a transaction is running. Custom merge drivers aren't going to run inside a transaction, so this doesn't affect that.
Tue, 06 Oct 2015 13:13:31 -0700 lock: add a way to prevent locks from being inherited
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 13:13:31 -0700] rev 26498
lock: add a way to prevent locks from being inherited We want to prevent locks from being inherited sometimes (e.g. when there's a currently running transaction, which will break a lot of assumptions we're making in here.)
Tue, 06 Oct 2015 15:55:50 -0700 test-fncache: use args/kwargs for lock wrapper
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 15:55:50 -0700] rev 26497
test-fncache: use args/kwargs for lock wrapper This is annoying to keep up to date, and also just plain unnecessary.
Tue, 06 Oct 2015 15:07:00 -0400 rebase: enable histedit for useful help with it
timeless@mozdev.org [Tue, 06 Oct 2015 15:07:00 -0400] rev 26496
rebase: enable histedit for useful help with it
Tue, 06 Oct 2015 15:01:25 -0400 rebase: suggest help -e histedit
timeless@mozdev.org [Tue, 06 Oct 2015 15:01:25 -0400] rev 26495
rebase: suggest help -e histedit Users unfamiliar with an extension should be reading the documentation for the feature, not the command.
Tue, 06 Oct 2015 15:05:40 -0400 rebase: factor out histedit help command
timeless@mozdev.org [Tue, 06 Oct 2015 15:05:40 -0400] rev 26494
rebase: factor out histedit help command
Sun, 04 Oct 2015 22:35:36 +0900 util: use tuple accessor to get accurate st_mtime value (issue4836)
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Oct 2015 22:35:36 +0900] rev 26493
util: use tuple accessor to get accurate st_mtime value (issue4836) Because st.st_mtime is computed as 'sec + 1e-9 * nsec' and double is too narrow to represent nanoseconds, int(st.st_mtime) can be 'sec + 1'. Therefore, that value could be different from the one got by osutils.listdir(). This patch fixes the problem by accessing to raw st_mtime by tuple index. It catches TypeError to fall back to st.st_mtime because our osutil.stat does not support tuple index. In dirstate.normal(), 'st' is always a Python stat, but in dirstate.status(), it can be either a Python stat or an osutil.stat. Thanks to vgatien-baron@janestreet.com for finding the root cause of this subtle problem.
Sun, 04 Oct 2015 22:25:29 +0900 util: extract stub function to get mtime with second accuracy
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Oct 2015 22:25:29 +0900] rev 26492
util: extract stub function to get mtime with second accuracy This function is trivial but will need a long comment why it can't use st.st_mtime. See the next patch for details.
Mon, 05 Oct 2015 14:37:59 -0700 scmutil: add a way for a repo's wlock to be inherited by a subprocess
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:37:59 -0700] rev 26491
scmutil: add a way for a repo's wlock to be inherited by a subprocess This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In the future, we'll call this for custom merge drivers.
Mon, 05 Oct 2015 14:34:52 -0700 scmutil: add a way for a subprocess to be run with an inheritable lock
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:34:52 -0700] rev 26490
scmutil: add a way for a subprocess to be run with an inheritable lock This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In an upcoming patch, we'll add an API for the wlock to be inherited.
Mon, 05 Oct 2015 14:27:37 -0700 localrepo: add a way to get the current wlock if it's held
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:27:37 -0700] rev 26489
localrepo: add a way to get the current wlock if it's held This will be useful to pass around a reference to the lock to some functions we're going to add to scmutil. We don't want those functions to live in localrepo to avoid bloat.
Mon, 05 Oct 2015 14:26:53 -0700 localrepo: add a way to get the current lock if it's held
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:26:53 -0700] rev 26488
localrepo: add a way to get the current lock if it's held We'll use this in upcoming patches to return a reference to the wlock if it's held.
Thu, 24 Sep 2015 13:58:18 -0400 test-help: verify that extension keywords appear in help templates
timeless@mozdev.org [Thu, 24 Sep 2015 13:58:18 -0400] rev 26487
test-help: verify that extension keywords appear in help templates fixed by a2291c9c85a1
Mon, 24 Aug 2015 23:30:17 -0400 templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2015 23:30:17 -0400] rev 26486
templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Sun, 23 Aug 2015 23:44:58 -0400 templater: introduce {latesttag()} function to match a pattern (issue4184)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Aug 2015 23:44:58 -0400] rev 26485
templater: introduce {latesttag()} function to match a pattern (issue4184) This allows the latest class of tag to be found, such as a release candidate or final build, instead of just the absolute latest. It doesn't appear that the existing keyword can be given an optional argument. There is a keyword, function and filter for 'date', so it doesn't seem harmful to introduce a new function with the same name as an existing keyword. Most functions are pretty Mercurial agnostic, but there is {revset()} as precedent. Even though templatekw.getlatesttags() returns a single tuple, one entry of which is a list, it is simplest to present this as a list of tags instead of a single item, with each tag having a distance and change count attribute. It is also closer to how {latesttag} returns a list of tags, and how this function works when not given a '%' operator.
Mon, 24 Aug 2015 23:07:00 -0400 templatekw: introduce showlatesttags() to handle {latesttag} keywords
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2015 23:07:00 -0400] rev 26484
templatekw: introduce showlatesttags() to handle {latesttag} keywords The keywords {changes}, {distance} and {tag} will be available on a future template method that will allow pattern matching against tag names. For consistency, these should be available on the existing {latesttag} keyword as well. I debated whether or not to add {tag} instead of just continuing with the existing {latesttag}. But it seems clearer not to have the same name for two distinct things (a list in the LHS of %, and an individual tag value on the right). The value of latesttags[0] is the date of commit for the cset to which the tag is applied (i.e. not the date the tag was applied), and therefore isn't made visible because it doesn't seem interesting. It appears that this is merely an internal implementation detail for sorting csets in a stable manner when there are different branches.
(0) -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip