Thu, 21 Aug 2014 16:05:29 -0700 clone: for local clones, copy over filtered branchcaches as well (issue4286)
Siddharth Agarwal <sid0@fb.com> [Thu, 21 Aug 2014 16:05:29 -0700] rev 22264
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
Thu, 21 Aug 2014 15:58:32 -0700 clone: for local clones, copy branchcache from the right location (issue4286)
Siddharth Agarwal <sid0@fb.com> [Thu, 21 Aug 2014 15:58:32 -0700] rev 22263
clone: for local clones, copy branchcache from the right location (issue4286) The unfiltered branchcache is in .hg/cache/branch2, not .hg/store/cache/branch2.
Wed, 20 Aug 2014 14:33:59 -0400 obsolete: avoid 2-argument form of enumerate, which was new in Python 2.6
Augie Fackler <raf@durin42.com> [Wed, 20 Aug 2014 14:33:59 -0400] rev 22262
obsolete: avoid 2-argument form of enumerate, which was new in Python 2.6
Wed, 20 Aug 2014 13:21:41 -0400 repoview: use util.sha1() instead of hashlib.sha1()
Augie Fackler <raf@durin42.com> [Wed, 20 Aug 2014 13:21:41 -0400] rev 22261
repoview: use util.sha1() instead of hashlib.sha1() 45b5cd948a4d accidentally broke Python 2.4 compatibility, this fixes it.
Mon, 18 Aug 2014 17:17:23 -0700 debugobsolete: display parents information from markers
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 Aug 2014 17:17:23 -0700] rev 22260
debugobsolete: display parents information from markers Now that we have a new field, we need a way to visualize it.
Mon, 18 Aug 2014 17:14:27 -0700 obsmarkers: add a `parentnodes` method to retrieve parent information
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 Aug 2014 17:14:27 -0700] rev 22259
obsmarkers: add a `parentnodes` method to retrieve parent information
Mon, 18 Aug 2014 16:28:44 -0700 obsstore: also store the 'parents' field on disk
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 Aug 2014 16:28:44 -0700] rev 22258
obsstore: also store the 'parents' field on disk We now store the `parents` field on disk. We use the same strategy as for `date`: We stick it into the metadata. This is slow and dirty, but this is also the only way we currently have. At some point we'll have a new obsstore format to store this properly.
Mon, 18 Aug 2014 17:06:08 -0700 obsstore: drop 'date' from the metadata dictionary
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 Aug 2014 17:06:08 -0700] rev 22257
obsstore: drop 'date' from the metadata dictionary We are extracting the `date` information from the metadata at read time. However, we failed to remove it from the metadata returned in the markers. This is now fixed.
Mon, 18 Aug 2014 16:17:16 -0700 createmarkers: automatically record the parent of pruned changesets
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 Aug 2014 16:17:16 -0700] rev 22256
createmarkers: automatically record the parent of pruned changesets We need this information to build the set of relevant markers during exchanges. This can only be done at the `createmarkers` level since the `obsstore.create` function does not have a repo and therefore has no access to the parent information.
Mon, 18 Aug 2014 16:12:29 -0700 obsstore: add a `parents` argument to obsstore.create
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 Aug 2014 16:12:29 -0700] rev 22255
obsstore: add a `parents` argument to obsstore.create We need a way to pass the information to the function. Some guru told me that what's arguments are made for.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip