• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

xolox / python-vcs-repo-mgr / 142
93%
master: 93%

Build:
Build:
LAST BUILD BRANCH: dev
DEFAULT BRANCH: master
Ran 02 Jul 2017 09:45PM UTC
Jobs 2
Files 7
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
142

push

travis-ci

xolox
Major rewrite: Named remotes, selective pushing, init support, etc.

Brain dump of changes:

 - What triggered me to start on a major rewrite was that I'd gotten fed
   up with the current (horrible) test suite because it depends on the
   cloning of remote public repositories which makes it slow and
   fragile. To underline why it is fragile:

   I only know of one place to find public Bazaar repositories which is
   Launchpad.net, however cloning a Bazaar repository from Launchpad
   fails more often than it works. Recently the `more often' turned into
   always and the test coverage of the Bazaar support in vcs-repo-mgr
   basically disappeared, without any action from me :-(.

   To improve the test suite I wanted to add support for `bzr init',
   `git init' and `hg init'. However that would have made the code even
   uglier than it already was and so the rewrite was triggered :-).

   Support for `init' has been added, by the way :-P. I've also added
   support for creating tags, otherwise I wouldn't have been able to
   test the support for tags :-).

   After the rewrite I also rewrote the test suite, it's a completely
   different beast now. Stil slow, but much more robust and with quicker
   feedback about individual tests.

 - The push() and pull() methods can work with specific revisions and
   merge_up() has been changed to pull a specific revision (the feature
   branch that it merges in).

 - The API between the Repository superclass and the subclasses that
   implement support for a specific version control system has been
   changed completely, in various backwards incompatible ways.

 - The new API enables introspection of `remotes' (the repositories from
   which you clone/pull and the repositories that you push to) which
   enables pull() to know whether a `default remote' is configured for
   any given repository.

 - The new API has a class to represent commit authors, enabling less
   ad-hoc communication between the superclass, its subclasses and
   callers.

 - In the process of rewriting everything I've switched to using
   execution contexts created by executor.contexts, this enables me to
   configure the working directory in two places instead of having to
   repeat the same thing in a hundred different places. This change also
   gives callers much more control over how external commands are
   executed (so much control that you can in theory run the commands on
   a remote system over SSH without having a version control system
   installed on your local system :-P).

 - Support for specific version control systems has been extracted from
   the main `vcs_repo_mgr' module into separate modules under the
   `vcs_repo_mgr.backends' namespace. The modules in the backends
   namespace are loaded on demand.

909 of 970 relevant lines covered (93.71%)

1.87 hits per line

Jobs
ID Job ID Ran Files Coverage
1 142.1 02 Jul 2017 09:45PM UTC 0
93.71
Travis Job 142.1
2 142.2 02 Jul 2017 09:45PM UTC 0
93.71
Travis Job 142.2
Source Files on build 142
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #142
  • 8a23b9d1 on github
  • Prev Build on dev (#136)
  • Next Build on dev (#143)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc