A set of scripts to work locally on Subversion checkouts using Mercurial
This set of scripts allows to work locally on Subversion-managed projects using the Mercurial distributed version control system.
Why use Mercurial ? You can do local (disconnected) work, pull the latest changes from the SVN server, manage private branches, submit patches to project maintainers, etc. And of course you have fast local operations like “hg log”, “hg annotate”…
Currenly two scripts are provided:
- hgimportsvn initializes an SVN checkout which is also a Mercurial repository.
- hgpullsvn pulls the latest changes from the SVN repository, and updates the Mercurial repository accordingly. It can be run multiple times.
Making a checkout of the Nose trunk:
$ mkdir nose && cd nose # Make SVN checkout, initialize hg repository with first SVN revision $ hgimportsvn http://python-nose.googlecode.com/svn/trunk $ cd trunk # Pull all history from SVN, creating a new hg changeset for each SVN rev $ hgpullsvn
You first need to install the pysvn library. Unfortunately it is not available as an easy_install package, so it can’t be automated in the setup script. In Debian and Ubuntu this package is named “python-svn” (not “python-subversion” which is a different package). In Mandriva it is named “python-pysvn” (not “python-svn” which is a different package).
hgpullsvn asks for SVN log entries in chunks, so that pulling history does not put the remote server on its knees.
hgpullsvn can be interrupted at any time, and run again later: you can pull history incrementally.
hgsvn reflects commit times (using the local timezone) and commit author names. Commit messages can contain Unicode characters.
File copies and renames as reflected as well, provided they occur inside the branch. SVN externals are purposefully ignored and won’t be added to your Mercurial repository.
These scripts encourage the use of named branches. All updates using hgpullsvn are made in the branch named from the last component of the SVN URL (e.g., if the SVN URL is svn://server/myproj/branches/feature-ZZZ, hgpullsvn will create and use the named branch ‘feature-ZZZ’).
You can thus do local development using your own named branches. When you want to fetch latest history from the SVN repository, simply use hgpullsvn which will update to the original (pristine) branch, leaving your local work intact (you can then merge by yourself if your want).
This also means that hg di -r name-of-pristine-branch will immediately give you a patch against the pristine branch, which you can submit to the project maintainers.
(Note: in a non-trivial setup where you work on several features or bugfixes, you will clone the pristine repository for each separate piece of work, which will still give you the benefit of named branches for quickly generating patches).
Detecting parent repository
If the SVN URL has been created by copying from another SVN URL (this is the standard method for branch creation), hgimportsvn tries to find an hgsvn repository corresponding to the parent SVN URL. It then creates the new repository by cloning this repository at the revision immediately before the creation of the SVN branch.
In other words, let’s say you are operating from myworkdir/. In myworkdir/trunk, you already have an hgsvn repository synced from svn://server/myproj/trunk. You then hgimport svn://server/myproj/branches/new-feature. It will find that the ‘new-feature’ branch has been created by copying from ‘trunk’ at rev. 1138. It will thus create the ‘new-feature’ hg repository by cloning from the ‘trunk’ repository at the revision immediately preceding rev. 1138: for example rev. 1135, identified by the local tag ‘svn.1135’.
This means you will have an hgsvn repository containing two named branches: ‘trunk’ for all the changesets in the trunk before rev. 1138, and ‘new-feature’ for all the changesets in the SVN branch (therefore, after rev. 1138). This way, you can easily track how the branch diverges from the trunk, but also do merges, etc.
- pysvn doesn’t really ignore externals, so use the command line for svn update instead (otherwise we get failures for obsolete URLs)
- .svn directories were not always ignored.
- On large repositories, adding more than 32765 files at once failed because of too many arguments on the command line.
- On slow SVN servers, the chunked log fetching algorithm ended up asking for 0 log entries.
Release history Release notifications | RSS feed
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size hgsvn-0.1.1-py2.4.egg (24.1 kB)||File type Egg||Python version 2.4||Upload date||Hashes View|
|Filename, size hgsvn-0.1.1-py2.5.egg (23.8 kB)||File type Egg||Python version 2.5||Upload date||Hashes View|
|Filename, size hgsvn-0.1.1.tar.gz (24.9 kB)||File type Source||Python version None||Upload date||Hashes View|