-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Really mirror the upstream repository + refactor Repo API #223
Conversation
This PR has lots of little moving parts, so some questions below, mainly just to double check:
So, the
Isn't that already the case? If I clone a git repository, I can access origin's branches by name (they don't exist locally, so you get a "detached head", but for checking it out and getting a log between two branches etc., it works). I'm not opposed to using
Seems reasonable.
Makes sense.
Yep.
Sure -- though maybe we can do something like
Good point. Those were originally used for tags, but obviously they are more general.
Seems useful in some cases. That reminds me that "continuous" is kind of a poor name choice for that command. Maybe "pairwise" would be better? Doesn't have to be part of this PR -- I'll open a new issue.
Here, I think I'm just missing something...
This makes sense.
Yeah -- if we ever wanted to do Subversion support, we could probably put a subversion repository (i.e. the whole history) at the top level and checkout revisions into the environments from there (rather than remotely), which would certainly speed things up. |
Both Git and Mecurial use hard links for cloning repository data locally, so the environment clones don't in practice hog performance/disk, even without For mercurial, explicit
Ok, indeed the origin branches can be accessed as "origin/foo", but not as "foo". It seems I was thinking about the use case I had with Scipy, where the clone is a clone of the local repository (the benchmarks are inside the main repo). In this case, if you clone the repository without But I think even without this use case, |
Ah, indeed that's the case for that use case. For the simpler case of cloning a remote repository, This all makes sense then. Thanks for clarifying. |
There's a few other known issues on Windows (mostly to do with timing itself), and I've never claimed support for it, so I've no problem with other Windows shortcomings unless someone comes along who cares enough to help maintain Windows issues. |
Thanks. I think this just needs a rebase and then I'm happy to merge. |
…repository Make the Repo object act transparently as a mirror of the remote repository. Also rework the logic so that a checkout of the working tree is done only in the environment-specific clones. This makes remote branches available for all commands without special prefixes, and removes the need for Repo.check_remote_branch. Also rename some of the commands, so that branch/tag/commit is called "name", and replace checkout_parent with get_hash_from_parent.
…work better for mercurial
Really mirror the upstream repository + refactor Repo API
This PR does the following refactoring:
checkout_parent
withget_hash_from_parent
get_hash_from_master
for getting master branch, to be nicer to Mercurialhg pull
on environment-specific repos, as--shared
in not used for hg_tag
->_name
in Repo methods where appropriateasv continuous
The main advantages of this is making all remote branches available to asv (which is what the user will likely expect) and not checking out unnecessary working trees. It also removes the concept of sub-Repo objects in the environment-specific clones, which is slightly simpler and may be better for Subversion.