Commit graph

4 commits

Author SHA1 Message Date
schmonz
bfe69cba06 Update to 1.06. From the changelog:
* Fix propagation of failure from pre and post hooks and from fixups.
* Support chaining to absolute paths.
* Add support for skip = lazy, a mode where mr only operates on
  repositories that are checked out.
2011-11-06 00:52:17 +00:00
schmonz
c8d6c1e2de Update to 1.05. From the changelog:
* README now gives a quick into to using mr.
* Brought back the "deleted" parameter, which provides an easy way
  to mark repositories that should be removed.
* Allow untrusted mrconfig files to set parameters to true/false.
  So skip=true or deleted=true can be used in an untrusted mrconfig
  file.
* Also allow order=N in an untrusted mrconfig file.
* Support bzr checkouts, which are updated with "bzr update", and
  to which bzr automatically pushes commits. Closes: #643589
* Use bzr branch, not deprecated bzr clone when registering bzr
  repositories. Closes: #643591
* Allow bzr branch|clone|get|checkout in untrusted mrconfig files.
* Avoid using sed -r in git-fake-bare, for OSX portability.
* git-fake-bare: handle fake bare repositories with core.bare not
  set (Thanks, Julien Rebetez)
2011-10-09 12:45:31 +00:00
schmonz
1cf7f79dcd Update to 1.04. From the changelog:
* Improve trust errors displayed while bootstrapping. Closes: #628234
* Allow mr register to be used with mrconfig file that does not yet
    exist. Closes: #629217
2011-06-21 02:57:11 +00:00
schmonz
8e564e44c2 Initial import of mr(1). From DESCR:
The mr(1) command can checkout, update, or perform other actions
on a set of repositories as if they were one combined respository.
It supports any combination of subversion, git, cvs, mercurial,
bzr, darcs, cvs, and fossil repositories, and support for other
revision control systems can easily be added. (There are extensions
adding support for unison and git-svn.)

It is extremely configurable via simple shell scripting. Some
examples of things it can do include:

* Update a repository no more frequently than once every twelve hours.
* Run an arbitrary command before committing to a repository.
* When updating a git repository, pull from two different upstreams
    and merge the two together.
* Run several repository updates in parallel, greatly speeding up
    the update process.
* Remember actions that failed due to a laptop being offline, so
    they can be retried when it comes back online.
2011-06-14 21:58:11 +00:00