Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 16 Sep 2014 17:52:40 -0700] rev 22852
obsolete: add a "format.obsstore-version" config option
This option controls what version of the binary format to use when creating a new
obsstore file.
Default is still the old format. No safeguards are currently placed around the
option value, but no clueless users are in danger of harm since it is
undocumented.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 00:10:10 -0700] rev 22851
obsolete: introduce a new binary encoding for obsmarkers (version 1)
This new encoding explicitly stores the date and parents allowing a
significantly faster marker decoding. See inline documentation for details.
This format is not yet used to store format on disk. But it will be used in
bundle2 exchange if both side support it. Support for on-disk format is coming
in other changesets.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 16:43:04 -0500] rev 22850
obsstore: add a flag for sha256 hashes
We add flag to inform that the marker is using sha256 hashes. As format 0 is not
able to handle sha256 hashes (32 bytes long), we plain crash if we even attempt to
encode a sha256 with it.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 00:15:04 -0700] rev 22849
obsolete: use uint## in the format documention
This is shorter and kind of more readable for people who care about binary
format.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 22:34:48 -0700] rev 22848
obsolete: gather _fm0 meta encoding with other _fm0 code
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 22:12:06 -0700] rev 22847
obsolete: _rename decodemeta to _fm0decodemeta
This will be format zero specific.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 22:11:36 -0700] rev 22846
obsolete: _rename encodemeta to _fm0encodemeta
This will be format zero specific.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 22:10:15 -0700] rev 22845
obsolete: store metadata as a tuple of (key, value) pairs (API)
Different formats will encode metadata in different ways. So we cannot keep the
binary blob in the object anymore. We use a tuple to ensure it is immutable and
hashable.
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 12:15:46 -0500] rev 22844
merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 11:38:00 -0500] rev 22843
templater: fix ifcontains when list is a string (issue4399)
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 08 Oct 2014 07:47:11 -0400] rev 22842
shelve: don't delete "." when rebase is a no-op (issue4398)
When unshelving and facing a conflict, if we resolve all conflicts in
favour of the committed changes instead of the shelved changes, then
the ensuing implicit rebase is a no-op. That is, there is nothing to
rebase. In this case, there are no extra intermediate shelve commits
to strip either. Prior to this change, the commit being unshelved to
would be marked for destruction in a rather catastrophic way.
The relevant part of the test case failed as follows:
$ hg unshelve -c
unshelve of 'default' complete
$ hg diff
warning: ignoring unknown working parent 33f7f61e6c5e!
diff --git a/a/a b/a/a
new file mode 100644
--- /dev/null
b/a/a
@@ -0,0 1,3 @@
a
c
x
$ hg status
warning: ignoring unknown working parent 33f7f61e6c5e!
M a/a
? a/a.orig
? foo/foo
$ hg summary
warning: ignoring unknown working parent 33f7f61e6c5e!
parent: -1:000000000000 (no revision checked out)
branch: default
commit: 1 modified, 2 unknown (new branch head)
update: 4 new changesets (update)
With this change, this test case now passes.
Martin von Zweigbergk <martinvonz@gmail.com> [Wed, 08 Oct 2014 14:16:53 -0700] rev 22841
merge: make error message consistent with other commands
If a merge is attempted when another merge is already ongoing, we give
the message "outstanding uncommitted merges". Many other commands
(such as backout, rebase, histedit) give the same message in singular
form. Since the singular form also seems to make more sense, let's use
that for 'hg merge' as well.
Augie Fackler <raf@durin42.com> [Fri, 10 Oct 2014 10:34:52 -0400] rev 22840
test-run-tests: add a test for detection of failure to start a server
This also highlights a bug: right now we print "2 failed" but we only
ran one test.
Kyle Lippincott <spectral@google.com> [Thu, 09 Oct 2014 17:00:29 -0700] rev 22839
run-tests: more accurate/helpful message than "diff generation failed"
Diff generation didn't really fail, it recognized that an hg serve server has
failed to start, and thus skipped the diff generation intentionally.
The most common reason for a server to fail to start is that the port was
already in use, so output HGPORT as well, to help finding it (since pgrep -f
'hg serve' is not sufficient, if the command line is something like 'hg -R main
serve')
Augie Fackler <raf@durin42.com> [Thu, 09 Oct 2014 15:10:40 -0400] rev 22838
run-tests: handle --jobs and --first gracefully
Without this change, --first causes currently-running tests to explode
in violent and surprising ways when their temporary directory gets
cleaned up. Now we just suppress failure messages from non-first
failures when running in --first mode.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Mon, 06 Oct 2014 16:35:02 -0400] rev 22837
config: use the same hgrc for a cloned repo as for an uninitted repo
This just copies the same local sample hgrc, except it sets the
default path to the repo it was cloned from.
This is cut-and-paste from the local sample hgrc, but I think it's
acceptable, since the two pieces of code are right next to each other
and they're small. There is danger of them going out of synch, but it
would complicate the code too much to get rid of this C&P.
I also add ui as an import to hg.py, but with demandimport, this
should not be a noticeable performance hit.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 08 Oct 2014 07:45:51 -0400] rev 22836
config: give a more detailed sample repo config
Some examples of the typical configurations that one might want to do
in an .hg/hgrc file. This includes a default-push that happens to
point to the same location as my-fork.
I insist on the myfork terminology for a server-side clone. Bitbucket,
Github, and others have widely popularised this meaning of "fork".
This also includes a gentle nudge to use a repo-specific username,
which is something that people might not instinctively realise is an
option.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:46:53 -0700] rev 22835
smartset: drop infamous ascending, descending
All your friends are dead.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:41:14 -0700] rev 22834
fullreposet: use `isascending` instead of `ascending` to recognise smartsets
`ascending` is going to be removed.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:41:26 -0700] rev 22833
fullreposet: use `sort` to enforce the order
The `ascending` and `descending` methods are useless.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:48:34 -0700] rev 22832
revancestors: replace `descending` with `sort(reverse=False)`
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:41:02 -0700] rev 22831
_descendants: replace `ascending()` with `sort()`
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:36:53 -0700] rev 22830
_descendants: directly use smartset
As `addset` objects are proper smartset objects, we do not need to make any
transformation of the result.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 03:29:55 -0500] rev 22829
baseset: explicitly track order of the baseset
A baseset starts without an explicit order. But as soon as a sort is requested,
we simply register that the baseset has an order and use the ordered version of
the list to behave accordingly.
We will want to properly record the order at creation time in the future. This
would unlock more optimisation and avoid some sorting.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 03:31:05 -0500] rev 22828
baseset: fix isascending and isdescending
We now have sufficient information to return the proper value there.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 03:26:18 -0500] rev 22827
baseset: prepare lazy ordering in __iter__
We'll explicitly track the order of the baseset to take advantage of the
ascending and descending lists during iteration.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 03:19:23 -0500] rev 22826
baseset: implement a fastasc and fastdesc
Baseset contains already-computed revisions. It is considered "cheap" to do
operations on an already-computed set. So we add attributes to hold version of
the list in ascending and descending order and use them for `fastasc` and
`fastdesc`. Having distinct lists is important to provide correct iteration in
all cases. Altering a python list will impact an iterator connected to it.
eg: not preserving order at iterator creation time
>>> l = [0, 1]
>>> i = iter(l)
>>> l.reverse()
>>> list(i)
[1, 0]
eg: corrupting in progress iteration
>>> l = [0, 1]
>>> i = iter(l)
>>> i.next()
0
>>> l.reverse()
>>> i.next()
0
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 11:03:30 -0700] rev 22825
baseset: stop inheriting from built-in list class
The baseset is doing more and more smartset magic and using its list-like
property less and less. So we store the list of revisions in an explicit
attribute and stop inheriting.
This requires reimplementing some basic methods.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:38:14 -0700] rev 22824
strip: stop calling `remove` on smartset
The `remove` method is not part of the smartset specification. We use a plain
old list comprehension instead.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:31:53 -0700] rev 22823
rebase: transform the smartset to a list before comparing with a list
This is highly suboptimal but smartsets are not comparable to lists yet.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:41:58 -0700] rev 22822
merge.update: use `first` instead of direct indexing
This makes it compatible with all smartset classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:33:47 -0700] rev 22821
qimport: use `first` and `last` instead of direct indexing
This makes it compatible with all smartset classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:16:59 -0700] rev 22820
rebase: use `last` instead of direct indexing
This makes it compatible with all smartset classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:14:53 -0700] rev 22819
mq: use `last` instead of direct indexing
This makes it compatible with all smartset classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:09:50 -0700] rev 22818
repair: use `first` instead of direct indexing
This makes it compatible with all smartset classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 23:45:07 -0700] rev 22817
rangeset: use `first` and `last` instead of direct indexing
This makes it compatible with all smarsets classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 23:37:39 -0700] rev 22816
revpair: use `first` and `last` instead of direct indexing
This makes it compatible with all smarsets classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 23:37:08 -0700] rev 22815
revsingle: use `last` instead of direct indexing
This makes it compatible with all smarsets classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 11:43:32 -0700] rev 22814
revset-limit: use boolean testing instead of `len(revs) < 1`
I'm not sure why we wrote it that way. But smartsets have faster/lazier non-zero
testing than length computation.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:18:08 -0700] rev 22813
filteredset: implement `first` and `last`
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 14:42:00 -0700] rev 22812
baseset: implement `first` and `last` methods
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 12:52:36 -0700] rev 22811
generatorset: implement first and last methods
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 11:57:59 -0700] rev 22810
addset: implement first and last methods
The implementation is non-lazy for now. One may want to make it more lazy in the
future.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 11:54:53 -0700] rev 22809
spanset: implement `first` and `last` methods
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 11:46:53 -0700] rev 22808
smartset: add first and last methods
In multiple places in the code, we use `someset[0]` or `someset[-1]`. This
works only because the `someset` is usually a baseset. For the same reason we
introduce a `first` and `last` methods to be implemented for all smartset
classes.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:20:00 -0700] rev 22807
getgraphlogrevs: remove user of baseset.append
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:04:16 -0700] rev 22806
getlogrevs: remove user of baseset.append
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 00:55:09 -0700] rev 22805
revset-last: remove user of baseset.append
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 10:57:01 -0700] rev 22804
revset-limit: remove user of baseset.append
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 00:12:56 -0700] rev 22803
mq: use `revs.sort()` to ensure the set is ascending
Sorting is super-cheap with the new smartset class, so we can use it to enforce
the order. Otherwise all smartset classes would have to allow direct indexing.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 06 Oct 2014 10:41:43 -0700] rev 22802
baseset: use default value instead of [] when possible
For pure cleanup purposes, we replace all the occurences of `baseset([])` with
`baseset()`.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 04 Oct 2014 06:17:18 -0700] rev 22801
generatorset: implement isascending and isdescending
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 21:11:56 -0700] rev 22800
generatorset: explicitly track iteration order
The expected iteration order may be different than the fast iteration order (eg:
ancestors(42) is expected to be iterated upward but is fast/lazy to compute
downward.
So we explicitly track the iteration order and enforce it if the manual
iteration is requested.
Default expected iteration order of a generator set is ascending because I'm
not aware of any descending revset that need a generatorset. The first to find
such descending revset will have the pleasure to make this configurable.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:23:02 -0700] rev 22799
addset: drop caching through generatorset
The utility of this cache is debatable (no visible benchmark impact) and using
generatorset for such purpose makes the code complicated.
We drop it for now. Someone can reintroduce a smart version of it in the future
if it is detected to be relevant.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 21:01:30 -0700] rev 22798
generatorset: get list-based fast iterations after the generator is consumed
When all revisions are known, we shortcut most of the class logic to use list
iteration instead. The cost of the sort is expected to be non-significant. The
list creation and sorting could be done lazily in the future. We have to copy
the list to not break existing iterator created before we finished consuming the
generator.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:48:28 -0700] rev 22797
generatorset: move iteration code into _iterator
_iterator handles the generator iteration. The `__iter__` method will need
changes to handle ordering-related information.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:43:48 -0700] rev 22796
generatorset: stop using a base as the _genlist
It does not add anything and makes it more complicated to have a simple baseset
implementation.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:12:02 -0700] rev 22795
generatorset: drop the leading underscore in the class name
This is a real smart set now.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:14:43 -0700] rev 22794
generatorset: update the docstring now that it is a smartset
The documentation was still stating that this class was not a smartset. We drop
that part.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:18:48 -0700] rev 22793
addset: drop the leading underscore from the class name
This class is now a real smartset.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Oct 2014 20:17:12 -0700] rev 22792
addset: this is a smartset, update the docstring
The documentation was still stating that this class is a not a smartset. We drop
that part.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 05:27:23 -0700] rev 22791
addset: use the ascending argument in _iterordered
Fix a bug where fastasc and fastdesc were iterator in the same order as
self._ascending.
Matt Mackall <mpm@selenic.com> [Wed, 08 Oct 2014 14:03:07 -0500] rev 22790
rebase: add help examples
Matt Mackall <mpm@selenic.com> [Wed, 08 Oct 2014 13:40:50 -0500] rev 22789
rebase: attempt to clarify --base