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.

spanset: implement `first` and `last` methods

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.

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.

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.

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.

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.

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.

baseset: use default value instead of [] when possible For pure cleanup purposes, we replace all the occurences of `baseset([])` with `baseset()`.

generatorset: implement isascending and isdescending

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.

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.

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.

generatorset: move iteration code into _iterator _iterator handles the generator iteration. The `__iter__` method will need changes to handle ordering-related information.

generatorset: stop using a base as the _genlist It does not add anything and makes it more complicated to have a simple baseset implementation.

generatorset: drop the leading underscore in the class name This is a real smart set now.