Generic VCS plugin framework

[Stefano Rivera]

At the moment the VCS plugins stop on each other (syntax-wise).

It'd make sense to have a generic framework to deal with the common bits of each VCS plugin.

Preferably before we end up with too many more of them...

[Keegan Carruthers-Smith (keegan-csmith)]

I think the anyvc plugin would be useful: http://bitbucket.org/RonnyPfannschmidt/anyvc/

I took a very brief look over the code and it seems to support bzr, hg, git and svn. And each Repository object has a __len__ and __getitem__ for counting and retrieving revisions. The code is still in active development, but maybe transplanting some code from it would be useful. I also do not know how well it works on remote repositories.

[Keegan Carruthers-Smith (keegan-csmith)]

So I just looked through the anyvc source and played with the API a bit. My conclusion is to not use it. Here are my thoughts why:

 * Calling __getitem__ on a repo essentially just passes it on to the underlying repo library. So for example with HG and SVN one can just pass integers, but BZR expects the ids. So to find new commits one cannot just iterate over the range [old_repo_length, new_repo_length)

 * Repo objects only have the method get_default_head, which returns a single head/tip/whatever the lingo. Revision objects then allow you to find its parents, so one could search backwards to find commits. The problem with this is you miss commits on other heads, if the head changes you will search all the way back to the initial commit, unless you store every head from the last time you polled the repo.

 * It doesn't seem to support remote mercurial repos. Nor does it seem to support cloning a remote repo, but I didnt look very hard for this.

All in all I say anyvc is not applicable. The best approach would be to take what we have and abstract away the repo polling from the user interaction.