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.

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.

smartset: drop infamous ascending, descending All your friends are dead.

fullreposet: use `isascending` instead of `ascending` to recognise smartsets `ascending` is going to be removed.

fullreposet: use `sort` to enforce the order The `ascending` and `descending` methods are useless.

revancestors: replace `descending` with `sort(reverse=False)`

_descendants: replace `ascending()` with `sort()`

_descendants: directly use smartset As `addset` objects are proper smartset objects, we do not need to make any transformation of the result.

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.

baseset: fix isascending and isdescending We now have sufficient information to return the proper value there.

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.

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

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.

strip: stop calling `remove` on smartset The `remove` method is not part of the smartset specification. We use a plain old list comprehension instead.

rebase: transform the smartset to a list before comparing with a list This is highly suboptimal but smartsets are not comparable to lists yet.

merge.update: use `first` instead of direct indexing This makes it compatible with all smartset classes.

qimport: use `first` and `last` instead of direct indexing This makes it compatible with all smartset classes.

rebase: use `last` instead of direct indexing This makes it compatible with all smartset classes.

mq: use `last` instead of direct indexing This makes it compatible with all smartset classes.

repair: use `first` instead of direct indexing This makes it compatible with all smartset classes.

rangeset: use `first` and `last` instead of direct indexing This makes it compatible with all smarsets classes.

revpair: use `first` and `last` instead of direct indexing This makes it compatible with all smarsets classes.

revsingle: use `last` instead of direct indexing This makes it compatible with all smarsets classes.

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.

filteredset: implement `first` and `last`

baseset: implement `first` and `last` methods

generatorset: implement first and last methods

addset: implement first and last methods The implementation is non-lazy for now. One may want to make it more lazy in the future.