Extend repository slicing to non numerical revisions about vcs HOT 6 CLOSED

I'm for it. In git that should be quite simple (i. e. for extreme fast implementation we can call git command).

from vcs.

One more thing, after implementing slicing, i notice that current (numerical) slicing works in odd way,

In [7]: import vcs; r = vcs.get_repo('/home/hg/vcs');list(r['3803844fdbd3':'dc5d2c0661b6']);list(r[7:9])
Out[7]: 
[<MercurialChangeset at 7:3803844fdbd3b711175fc3da9bdacfcd6d29a6fb>,
 <MercurialChangeset at 8:dc5d2c0661b61928834a785d3e64a3f80d3aad9c>]
Out[7]: 
[<MercurialChangeset at 246:cc3ef1b53735ad82c97686d97ef3e65ae7586aef>,
 <MercurialChangeset at 245:690f784528ee3a5612ec50b475182ffa2e551783>]

Revisions are reversed I would expect when i reach for 7:9 i would get them, You think this should be fixed ?

from vcs.

Well...

This is because iter at BaseRepository reverses changesets. It was design decision we did a long ago - it allows construction as this:

for cs in repo:
    print cs

To show changesets in ~"historical" order. I believe we can change that - but all external codes that depends on this structure should be reviewed. Nevertheless, I suppose we should change that so slices would gives us changeset instances in same order as slices of Repository.revisions.

from vcs.

We need to stabilize API for Repository.iter, Repository.getslice and Repository.get_changesets ASAP.

I'm also not happy with parameters allowed at get_changests. There should be at least couple of more parameters (start/end date, first/last changeset, branch name, limit, remove offset probably as it is not as straightforward as should be).

Maybe we should rename this issue, schedule it for 0.2 and change from "proposal" to "enhancement" ?

from vcs.

Ok, i'd think i stabilize the api by latests commits. both git and hg act the same when iterating, slicing, and using getitem

from vcs.

Duplicate of #44

from vcs.