Augie Fackler <raf@durin42.com> [Fri, 10 Oct 2014 14:09:37 -0400] rev 22942
manifest: rename ambiguously-named set to setflag
Just makes it a little clearer what this method does.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 08:29:31 -0700] rev 22941
bookmarks: inform transaction-related hooks that some bookmarks were moved
We do not have enough information to provide any finer data, but this is still
useful information.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 08:03:20 -0700] rev 22940
phases: inform transaction-related hooks that a phase was moved
We do not have enough information to provide finer data, but this is still
useful information.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 13 Oct 2014 14:52:38 -0700] rev 22939
test-bundle2: also test the argument of the changegroup hook
We also track execution of the changegroup hook. The important information here
is to make sure the information that the transaction was processing a bundle2 is passed to
hook. This will let most hooks disable themselves while waiting for the hook
concluding bundle2 processing (the one we discovered to be not called for
pull in the previous changesets).
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 13 Oct 2014 14:47:36 -0700] rev 22938
test-bundle2: test that we got appropriate hook called with appropriate data
We can notice that this transaction wide hook is only happening during push and
it is missing changegroup-related information. We'll want to fix this but this
is not what this patch is about.
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Oct 2014 06:40:36 -0700] rev 22937
pull: use `stepsdone` instead of `todosteps`
The push process uses a `stepsdone` attribute instead of a `todosteps` one (with
the logic swapped). We unify the two process by picking the `stepsdone` version.
I feel like `stepsdone` better fits extensions that would want to extend the push
exchange process.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 27 Sep 2014 00:29:06 -0700] rev 22936
pull: make discovery phase extensible
We apply the same approach as for push and make the discovery extensible. There
is only one user in core right now, but we already know we'll need something
smarter for obsmarkers. In fact the evolve extension could use this to cleanly
extend discovery.
The main motivation for this change is consistency between push and pull.
Yuya Nishihara <yuya@tcha.org> [Tue, 14 Oct 2014 21:59:39 +0900] rev 22935
sshpeer: forward stdout of remote "hg init" to appropriate output channel
Otherwise, commandserver channel could be corrupted.
Mike Edgar <adgar@google.com> [Wed, 03 Sep 2014 16:34:29 -0400] rev 22934
revlog: support importing censored file revision tombstones
This change allows a revision log to not fail integrity checks when applying a
changegroup delta (eg from a bundle) results in a censored file tombstone. The
tombstone is inserted as-is, so future integrity verification will observe the
tombstone. Deltas based on the tombstone will also remain correct.
The new code path is encountered for *exactly* the cases where _addrevision is
importing a tombstone from a changegroup. When committing a file containing
the "magic" tombstone text, the "text" parameter will be non-empty and the
checkhash call is not executed (and when committing, the node will be computed
to match the "magic" tombstone text).
Mike Edgar <adgar@google.com> [Tue, 14 Oct 2014 16:16:04 -0400] rev 22933
verify: report censored nodes if configured policy is abort
Mike Edgar <adgar@google.com> [Tue, 14 Oct 2014 15:46:16 -0400] rev 22932
context: handle censored data in an on-disk file context based on config
Two possible behaviors are defined for handling censored data: abort, and
ignore. When we ignore censored data we return an empty file to callers
requesting the file data.
Augie Fackler <raf@durin42.com> [Wed, 08 Oct 2014 15:20:14 -0400] rev 22931
manifest: add fastdelta method to manifestdict
This is another step closer to alternate manifest implementations that
can offer different hashing algorithms.
Augie Fackler <raf@durin42.com> [Wed, 08 Oct 2014 15:21:59 -0400] rev 22930
manifest: move _search to module level and rename to _msearch
The rename is intended to provide a slight hint that it is
manifest-specific.
Augie Fackler <raf@durin42.com> [Wed, 08 Oct 2014 14:47:30 -0400] rev 22929
manifest: move manifestdict-to-text encoding to manifest class
A future patch will introduce a new format, with a new class.
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 13:22:31 -0700] rev 22928
localrepo: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 11 Oct 2014 22:43:14 -0700] rev 22927
subrepo: use separate instances of empty lists in status
We do modify the lists that make up the status in several places, so
it seems risky to use the same instance of a list for several
different status types. Use a separate empty list for each type
instead.
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 09:29:48 -0700] rev 22926
summary: make status code more readable
In commands.summary(), we currently zip a list of labels with a list
of statuses. This means the order of the status list has to match the
list of the labels, which in turn means the status elements have to be
inserted into specific places in the list. Let's instead group the
labels and status data we want to display in a single list of pairs.
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 20:53:05 -0700] rev 22925
strip: make checklocalchanges() return full status tuple
By making checklocalchanges() return the full instance of the status
class instead of just the first 4 elements of it, we can take
advantage of the field names and not require the caller to remember
the element indices.
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 21:58:01 -0700] rev 22924
fileset: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 21:19:44 -0700] rev 22923
histedit: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 22:12:43 -0700] rev 22922
shelve: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 10:44:07 -0700] rev 22921
record: access status fields by name rather than index
It is safe to pass the full status to patch.diff() since it does its
own slicing.
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 10:38:43 -0700] rev 22920
purge: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 22:10:08 -0700] rev 22919
largefiles: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 10:05:54 -0700] rev 22918
keyword: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 09:51:39 -0700] rev 22917
hgcia: access status fields by name rather than index
Martin von Zweigbergk <martinvonz@gmail.com> [Sat, 04 Oct 2014 21:05:41 -0700] rev 22916
context: store status class instead of plain tuple in self._status
This improves readability a bit by allowing us to refer to statuses by
name rather than index.
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 10 Oct 2014 10:14:35 -0700] rev 22915
status: update and move documentation of status types to status class
The various status types are currently documented on the
dirstate.status() method. Now that we have a class for the status
types, it makese sense to document the status types there
instead. Only leave the bits related to lookup/unsure in the status()
method documentation.
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 00:52:27 -0500] rev 22914
status: update various other methods to return new class
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 10 Oct 2014 14:32:36 -0700] rev 22913
status: create class for status lists
Callers of various status() methods (on dirstate, context, repo) get a
tuple of 7 elements, where each element is a list of files. This
results in lots of uses of indexes where names would be much more
readable. For example, "status.ignored" seems clearer than "status[4]"
[1]. So, let's introduce a simple named tuple containing the 7 status
fields: modified, added, removed, deleted, unknown, ignored, clean.
This patch introduces the class and updates the status methods to
return instances of it. Later patches will update the callers.
[1] Did you even notice that it should have been "status[5]"?
(tweaked by mpm to introduce the class in scmutil and only change one user)