Thanks for working on this, generally looks great! More tests would be excellent, though I'd probably merge it with the current level of testing, pending comments above.

ok, cool, I'll post some updates in a day or two.

I think i've addressed everything that's been mentioned

questions:

1. whether we should "fix" issue 495 (see comments in that issue). in this branch, it's "fixed"
2. whether to use my new "path_in_dir" function or just to fall back to the old code

next weekend (when I have some more time) I plan on getting my environment straight once and for all, so I can pass all the tests.
currently, I always have some stragglers that fail. I'll feel more confident after that.

tests I've been running:
--linux: py24, py25, py26, py27, py32
--windows: py27

lgtm - if you're happy with your testing

ok, I worked on my environments, and ran tests again for
linux: py24, py25, py26, py27, py32
windows: py27

for linux testing, down to 2 unrelated failures:

1. 1 bz2 test failing for my non-py26 installs, due to it not being compiled in those py versions
2. test_vcs_backends.test_git_with_tag_name_and_update fails across the board due to my git version having a different format for that kind of error

on windows:

1. various failures related to my svn installation that I didn't take the time to sort out. I'm pretty out of touch with svn config on windows.
2. a few failures because I don't have bzr installed

Github is complaining about mergability. I can try merge and thus cause a travis CI run on my personal develop branch, or maybe we can wait a little longer and get the test on pull request working see Issue #527

I'm willing to rebase my userscheme branch on my locally updated develop branch (and retest) and then force push userscheme to my origin. github shouldn't complain then about you merging userscheme, but I guess that would blow away all the comment references in this pull request. so probably not desired?

Are you on #pip on freenode? May be easier to discuss there.

ok, I think I did what we talked about on #pip
there's was just a minor conflict in util.py in the import lines.
tests still look good.

Carl/Paul:

I fear the scope of this branch has gotten too large for anyone to feel comfortable merging it.
I'm willing break this up into a series of smaller pull requests that build up to the same result.
The commit history in the smaller pulls would be much cleaner a 2nd time through, now that I've sorted thru all the issues.

let me know, if you think that would help?

If you feel willing and more comfortable doing that - that's fine with me.

However I'm probably happy enough to merge this shortly - I was hoping to fix #530 first so we have a good green build to depend on.

hmm...It's hard to decide. I know I'm more making more work for myself. : )
I'm inclined to be really conservative knowing pip is so widely used, and honestly I'm pretty new to contributing to a major project like this.
A series of smaller pulls with clear/concise commit histories would probably serve the history of the project better.
I have time this weekend, so I could start on it.

OTOH, if that sounds like more work for you, I understand.

That works for me, thanks for all your work on this! I'm travelling back home this weekend so I wouldn't expect responsiveness, but I'll try address next week.

I'm with Paul - I wouldn't have asked you to do that extra work, but I do find more smaller pull requests easier to deal with when possible.

here's my plan for breaking this up
https://gist.github.com/2822510

I'll reference the plan when I do requests.

closing, as this request is being handled in smaller parts:
https://gist.github.com/2822510