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.