Tue, 14 Oct 2014 00:06:46 -0700 changegroup: store source and url in the `hookargs` dict
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:06:46 -0700] rev 22971
changegroup: store source and url in the `hookargs` dict We store the source and url of the current data into `transaction.hookargs` this let us inherit it from upper layers that may have created a much wider transaction. We have to modify bundle2 at the same time to register the source and url in the transaction. We have to do it in the same patch otherwise, the `addchangegroup` call would fill these values and the hook calling will crash because of the duplicated 'source' and 'url' arguments passed to the hook call.
Tue, 14 Oct 2014 00:43:20 -0700 prechangegroup: use hook argument from the transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:43:20 -0700] rev 22970
prechangegroup: use hook argument from the transaction There can be useful data in there (eg: bundle2 related one)
Tue, 14 Oct 2014 00:09:25 -0700 addchangegroup: call `prechangegroup` hook after transaction retrieval
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:09:25 -0700] rev 22969
addchangegroup: call `prechangegroup` hook after transaction retrieval We want to reused some possible information stored in the transaction `hookargs` dict that may be stored by something handling the transaction at an upper level (eg: bundle2) So we move the running of the hooks after transaction creation. This has no visible effects (but an empty transaction roolback if the hook fails) because nothing had happened in the transaction yet.
Tue, 14 Oct 2014 00:03:03 -0700 addchangegroup: get the `node` argument of `incoming` hook from transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:03:03 -0700] rev 22968
addchangegroup: get the `node` argument of `incoming` hook from transaction The transaction is now carrying hook-related informations. So we use it to retrieve the `node` argument. This will also carry around all kinds of other useful informations (like: "are we in a bundle2 processing")
Tue, 14 Oct 2014 23:53:35 -0700 dicthelpers: delete now that they are no longer used
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 23:53:35 -0700] rev 22967
dicthelpers: delete now that they are no longer used
Tue, 14 Oct 2014 23:18:07 -0700 manifest: transpose pair of pairs from diff()
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 23:18:07 -0700] rev 22966
manifest: transpose pair of pairs from diff() It makes more sense for the file nodeids and returned from diff() to be ((n1,fl1),(n2,fl2)) than ((n1,n2),(fl1,fl2)), so change it to the former.
Tue, 14 Oct 2014 22:48:44 -0700 manifest: for diff(), only iterate over files, not flags
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 22:48:44 -0700] rev 22965
manifest: for diff(), only iterate over files, not flags From manifest.diff(), we return a dict from filename to pairs of pairs of file nodeids and flags (values of the form ((n1,n2),(fl1,fl2))). To create this dict, we currently generate one dict for files (with (n1,n2) values) and one for flags (with (fl1,fl2) values) and then join these dicts. Missing files are represented by None and missing flags by '', but due to the dict joining, the inner pairs themselves can also be None. The only caller, merge.manifestmerge(), then unpacks these values while checking for None values. By inlining the calls to dicthelpers and simplifying it to only iterate over files (ignoring flags-only differences), we can simplify life for our caller.
Tue, 14 Oct 2014 17:09:16 -0700 manifest: repurpose flagsdiff() into (node-and-flag)diff()
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 17:09:16 -0700] rev 22964
manifest: repurpose flagsdiff() into (node-and-flag)diff() The manifestdict class already has a method for diff flags between two manifests (presumably because there is no full access to the private _flags field). The only caller is merge.manifestmerge(), which also wants a diff of files between the same manifests. Let's combine the code for diffing files and flags into a single method on manifestdict. This puts all the manifest diffing in one place and will allow for further simplification. It might also be useful for it to be encapsulated in manifestdict if we later decide to to shard manifests. The docstring is intentionally unclear about missing entries for now.
Thu, 16 Oct 2014 17:03:21 +0900 util: add a file handle wrapper class that does hash digest validation
Mike Hommey <mh@glandium.org> [Thu, 16 Oct 2014 17:03:21 +0900] rev 22963
util: add a file handle wrapper class that does hash digest validation It is going to be used for the remote-changegroup feature in bundle2.
Thu, 16 Oct 2014 17:02:51 +0900 util: add a helper class to compute digests
Mike Hommey <mh@glandium.org> [Thu, 16 Oct 2014 17:02:51 +0900] rev 22962
util: add a helper class to compute digests It is going to be used for the remote-changegroup feature in bundle2.
Thu, 16 Oct 2014 16:03:04 +0900 bundle2: merge return values when bundle contains multiple changegroups
Mike Hommey <mh@glandium.org> [Thu, 16 Oct 2014 16:03:04 +0900] rev 22961
bundle2: merge return values when bundle contains multiple changegroups A bundle2 may contain multiple parts adding changegroups, in which case there are multiple operation records for changegroups, each with its own return value. Those multiple return values are aggregated in a single cgresult value for the whole operation. As can be seen in the associated test case, the situation with hooks is not really the best, but without deeper thoughts and changes, we can't do much better. Hopefully, things will be improved before bundle2 is enabled by default. In the meanwhile, multiple changegroups is not expected to be in widespread use, and even less expected to be used for pushes. Also, not many clients cloning or pulling bundle2 with multiple changesets are not expected to have changegroup hooks anyways.
Thu, 16 Oct 2014 15:54:53 +0900 changegroup: use a copy of hookargs when invoking the changegroup hook
Mike Hommey <mh@glandium.org> [Thu, 16 Oct 2014 15:54:53 +0900] rev 22960
changegroup: use a copy of hookargs when invoking the changegroup hook addchangegroup creates a runhook function that is used to invoke the changegroup and incoming hooks, but at the time the function is called, the contents of hookargs associated with the transaction may have been modified externally. For instance, bundle2 code affects it with obsolescence markers and bookmarks info. It also creates problems when a single transaction is used with multiple changegroups added (as per an upcoming change), whereby the contents of hookargs are that of after adding a latter changegroup when invoking the hook for the first changegroup.
Thu, 16 Oct 2014 13:48:51 +0900 tests: pull common http server setup out of individual tests
Mike Hommey <mh@glandium.org> [Thu, 16 Oct 2014 13:48:51 +0900] rev 22959
tests: pull common http server setup out of individual tests There are currently two different tests using roughly the same code to create temporary scripts acting as HTTP servers. As there is going to be at least one more in an upcoming change, factor those out in a standalone dumbhttp.py script.
Wed, 24 Sep 2014 16:00:47 +0900 util: move md5 back next to sha1 and allow to call it without an argument
Mike Hommey <mh@glandium.org> [Wed, 24 Sep 2014 16:00:47 +0900] rev 22958
util: move md5 back next to sha1 and allow to call it without an argument This effectively backs out changeset 908c5906091b. The API change is done so that both util.sha1 and util.md5 can be called the same way. The function is moved in order to use it for md5 checksumming for an upcoming bundle2 feature.
(0) -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 +10000 tip