Putting asv.conf.json on project top level

[pv]

Putting asv.conf.json on project repository top level has the advantage that running asv commands no longer requires cd to somewhere else. However, it usually also requires putting the repository clone to somewhere else than conf.project.

• Add config option mirror_dir for specifying the mirror location. Change the default value be "project" --- the mirror is a bare repository, so looking inside it is not usually useful.
• Make asv quickstart provide also a default config more suitable for putting on project top level.

This also requires gh-307 to work

[mdboom]

This seems like an API change -- I think if conf.mirror_dir is not provided, it should fall back to the value of conf.project, whereas it appears that now it will default to (the literal) "project".

[pv]

Yes, it's an API change. I thought that because the mirrored repository in general is bare and there's no working tree, the name of the directory is not important. It's of course possible to change it to default to config.project if that's better.

[mdboom]

It probably doesn't matter, but it seems relatively cheap to maintain the old behavior here so we probably should.

[pv]

Ok, changed the default value.

[pv]

One alternative to mirror_dir could be to not use a mirror repository for local repositories.
This could be a cleaner solution to the problem: master...pv:no-mirror-for-local

[mdboom]

In the alternative solution, the project url becomes a local filesystem path, right. Doesn't that then mean the responsibility is on the user (or something outside of asv) to make sure that repo is updated? As it stands, asv handles pulling from a remote repo.

[pv]

It's the user's responsibility to update the source repo always when using a local path.
asv doesn't do anything to the source repo except cloning from it, all operations are done on the mirror one (and pull() on the mirror repo just pulls from the source repo on the local filesystem).

[mdboom]

Sorry -- that's right: I haven't used local paths much myself, but that seems like the right thing to do. (i.e. asv manages it entirely or the user manages it and asv treats it as "read-only").

[pv]

Yes, the effect in the end is the same as if there was no mirror repository when the path is local. The only difference AFAICS is that you can't use the HEAD and FETCH_HEAD references and the reflog syntax master@{3} since these are not preserved by clone --mirror. Since these are often useful, it would be best to just skip the mirroring.

[pv]

Actually, it probably doesn't hurt to have both mirror_dir config variable and to not use mirrors for local repos. The other directory names are also configurable, and the project config also affects what's shown in the HTML output.

[pv]

Dropped the mirror_dir stuff, but left the quickstart changes...

[pv]

Planning to merge soon.

[mdboom]

I think the Python 2.6 failure on AppVeyor is just a spurious something... I've restarted.

[pv]

The appveyor builds have sporadic failures with "error 5: permission denied" on rmtree-ing build environments. We have the one knownfailure test that exhibits this reliably on some (but not all) python versions, but apparently similar issue can appear elsewhere.

It's unclear how specific this is to appveyor; I don't recall being able to repro them locally, and don't have a VM at hand currently. gh-280 has some discussion.

[coveralls]

Coverage increased (+0.2%) to 53.427% when pulling 79cd793 on pv:samerepo into d82dcde on spacetelescope:master.