Mercurial > hgsubversion
view README @ 634:a400f3bf5611
replay/stupid: fix tagging on a branch renamed using a branch map
Previously, both convert_rev() functions used parentctx.extra() to
determine the branch to pass to meta.movetag(). This assumed that the
branch name stored in the changeset matches the internal branch. The
introduction of branch maps made this assumption unsafe, however: Now,
the Mercurial branch can be completely unrelated to the origin of the
changeset.
It turns out, however, that movetag() already has sufficient knowledge
to determine the branch. Given the hash of the new changeset to be
tagged, we walk its ancestors until we find an open changeset, which
we then know to be the originating branch. This assumes that there
were `few' commits made to the tag; an assumption I would consider
reasonable.
author | Dan Villiom Podlaski Christiansen <danchr@gmail.com> |
---|---|
date | Sun, 11 Jul 2010 11:46:19 +0200 |
parents | ebecf034e52a |
children | f12257bf8b91 |
line wrap: on
line source
.. -*-restructuredtext-*- ============ hgsubversion ============ hgsubversion is an extension for Mercurial that allows using Mercurial as a Subversion client. At this point, hgsubversion is usable by users reasonably familiar with Mercurial as a VCS. It's not recommended to dive into hgsubversion as an introduction to Mercurial, since hgsubversion "bends the rules" a little and violates some of the typical assumptions of early Mercurial users. Installation ------------ You need to have Subversion installed with the SWIG Python bindings from Subversion 1.5 or later. You need Mercurial 1.3 or later. .. _mercurial: http://selenic.com/repo/hg .. _mercurial-stable: http://selenic.com/repo/hg-stable .. _crew: http://hg.intevation.org/mercurial/crew .. _crew-stable: http://hg.intevation.org/mercurial/crew-stable If you are unfamiliar with installing Mercurial extensions, please see the UsingExtensions_ page in the Mercurial wiki. Look at the example for specifying an absolute path near the bottom of the page. You want to give the path to the top level of your clone of this repository. .. _UsingExtensions: http://mercurial.selenic.com/wiki/UsingExtensions Before using hgsubversion, I *strongly* encourage you to run the automated tests. Just use nose_ if you have it (or ``easy_install nose`` if you want it), or use ``python tests/run.py`` to run the suite with the conventional test runner. Note that because I use nose, there's a lot of stdout spew in the tests right now. The important part is that all the tests pass. .. _nose: http://code.google.com/p/python-nose/ Basic Use ----------- Get a new clone of an svn server:: $ hg clone <svn URI> [destination] Real example:: $ hg clone http://python-nose.googlecode.com/svn nose-hg Note, you should pull from the root subversion directory, not specific folders (such as trunk). Pull new revisions into an already-converted repo:: $ hg pull For more information, see ``hg help svn`` while in a converted repo. Support for ``svn:externals`` ----------------------------- All ``svn:externals`` properties are serialized into a single ``.hgsvnexternals`` file having the following syntax:: [.] common1 http://path/to/external/svn/repo1 ...additional svn:externals properties lines... [dir2] common2 -r123 http://path/to/external/svn/repo2 ...additional svn:externals properties lines... A header line in brackets specifies the directory the property applies to, where '.' indicates the project root directory. The property content follows the header, **with every content line being prefixed by a single space**. Note that the property lines have a format identical to svn:externals properties as used in Subversion, and do not support the hgsubversion extended svn+http:// URL format. Issuing the command ``hg svn updateexternals`` with the ``.hgsvnexternals`` example above would fetch the latest revision of repo1 into the subdirectory ./common1, and revision 123 of repo2 into dir2/common2. Note that ``.hgsvnexternals`` must be tracked by Mercurial before this will work. If ``.hgsvnexternals`` is created or changed, it will not be pushed to the related Subversion repository, *but its contents will be used to update ``svn:externals`` properties on the related Subversion repository*.