Error cloning a repository with a long and tragic history

Create issue
Issue #389 new
Tom Anderson created an issue

We have a Subversion repository that started life as a CVS repository, and was then converted. It has been through a variety of unfortunate experiences since then, as many Subversion repositories have. As a result, the early history is fairly dirty, but from a certain point onwards (r34722, to be precise), it is clean: the repository has the normal trunk/branches/tags layout, and i am not aware of any corruption. Here's me checking out the first revision:

$ svn co -r 34722
A    trunk/.cvsignore
A    trunk/build.xml
Checked out revision 34722.

I would like to clone this repository with hgsubversion, and i am entirely happy to do this only for the clean portion of its history. Here's me attempting to check it out out from the tip:

$ hg clone
destination directory: HIP
** Unknown exception encountered with possibly-broken third-party extension hgsubversion

... and a long stacktrace (which appears after several seconds of no output) which i attach as trace1.txt. There seem to be two errors in the trace. The fundamental one is:

subvertpy.SubversionException: ("REPORT of '/opt/repo/projects/!svn/bc/116733/HIP': 200 OK (", 175002)

And there is an error when handling this:

TypeError: Error when calling the metaclass bases
    module.__init__() takes at most 2 arguments (3 given)

Which suggests an incompatibility with my version of either Python or Mercurial, not sure.

If i look in the Subversion server's Apache error log, then i see entries from a second or so after i start the clone (but several seconds before it errors out):

[Wed Apr 03 19:17:38 2013] [error] [client] Could not fetch resource information.  [301, #0]
[Wed Apr 03 19:17:38 2013] [error] [client] Requests for a collection must have a trailing slash on the URI.  [301, #0]
[Wed Apr 03 19:17:39 2013] [error] [client] Could not fetch resource information.  [301, #0]
[Wed Apr 03 19:17:39 2013] [error] [client] Requests for a collection must have a trailing slash on the URI.  [301, #0]
[Wed Apr 03 19:17:53 2013] [error] [client] Provider encountered an error while streaming a REPORT response.  [500, #0]
[Wed Apr 03 19:17:53 2013] [error] [client] (104)Connection reset by peer: Error flushing brigade.  [500, #0]

Okay, so i can't do a simple checkout. The same thing happens if i try to check out just the trunk; the trace is identical bar the differences in the paths.

Never mind, i know the starting revision i want, so try that:

$ hg clone --startrev 34722
destination directory: HIP
abort: non-zero start revisions are only supported for single-directory clones.

Okay, so just get the trunk:

$ hg clone --startrev 34722
destination directory: trunk
** Unknown exception encountered with possibly-broken third-party extension hgsubversion

Exactly the same error as without the --startrev. Again, the trace is identical bar the difference in path.

Okay, so maybe there is some kind of trouble back in the history. The latest revision is r116733, so try that:

$ hg clone --startrev 116733
destination directory: trunk
no changes found
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Er. What?

$ find trunk/

No files!

After extensive experimentation, i find that revisions further into the past do work, the earliest one apparently being r38550:

$ rm -rf trunk; hg clone --startrev 38550
destination directory: trunk
[r38550] bsanders: 0008990: Sub Fund Performance Screen - please add "Final" mode

If i look at that, the latest revision is r116680 (a bit earlier than the r116733 reported by svn co). Cloning using that as a startrev works (and only gets a single revision, of course).

There are a few potential issues in here.

  1. Why does the "Error when calling the metaclass bases" exception happen?
  2. Why does cloning without specifying a start revision fail? I had the idea that hgsubversion would walk back from the tip to find a usable start point.
  3. Why does cloning with a start revision not allow a trunk-and-branches clone? This has been covered in other issues, i suspect.
  4. Why does a single-directory clone of a known-good revision fail?
  5. Why does a single-directory clone of the latest revision find no files? This is presumably because the revision i tried is the latest revision of the entire repository, rather than being a revision in which this project was touched, and so there are no changes to the project after that revision; i'm not sure what i would want hgsubversion to do in that situation instead of producing an empty clone, but a warning that was being stupid might help.

I am happy to perform further tests if they would help.


$ grep hgsubversion ~/.hgrc 
hgsubversion = /opt/hgsubversion/hgsubversion
tanderson@ldn-dev-tanderson ~ $ hg -R /opt/hgsubversion log -r . --template '{rev}:{node|short} {date|isodate} {latesttag}+{latesttagdistance}\n'
998:8045ebda705a 2013-03-10 19:32 +1000 1.5+24

$ hg --version
Mercurial Distributed SCM (version 2.5.2+2-605c7c94fd70)

$ dpkg -s python-subvertpy | grep Version
Version: 0.8.10-1

$ dpkg -s libsvn1 | grep Version
Version: 1.6.17dfsg-3ubuntu3

Comments (1)

  1. Log in to comment