`hg clone -r` broken when hgsubversion activated

Issue #467 resolved
Michael Howitz
created an issue

I use mercurial 4.3.1 and py27-hgsubversion-devel @1.8.99_6 (from MacPorts which seems to be the tip of the default branch from 2017-06-06, see https://github.com/macports/macports-ports/commit/e77a5d1c379d1765644799bad14713d1ed53ae35).

Calling hg clone -r 1.8.7 <source-URL> <target-path> results in a checkout having revision 1 as parent of the working directory instead of the revision which belongs to the tag 1.8.7.

This happens when cloning a mercurial repository! Disabling hgsubversion via .hgrc restores the expected behaviour.

Example calls:

With hgsubversion disabled:

$ hg clone -r 1.8.7 https://bitbucket.org/durin42/hgsubversion tmp1
adding changesets
adding manifests
adding file changes
added 1369 changesets with 2837 changes to 251 files
updating to branch stable
206 files updated, 0 files merged, 0 files removed, 0 files unresolved

With hgsubversion enabled:

$ hg clone -r 1.8.7 https://bitbucket.org/durin42/hgsubversion tmp2
adding changesets
adding manifests
adding file changes
added 9 changesets with 29 changes to 19 files
updating to branch default
14 files updated, 0 files merged, 0 files removed, 0 files unresolved

It seems that this was fixed on the default branch later on as it does not happen with the current tip.

So may I kindly ask for a new release to get this one fixed as well as #465?

Comments (1)

  1. Log in to comment