Windows binaries and hg convert from Subversion

[Paul Moore]

On 19/12/2007, Patrick Mézard <pmezard at gmail.com> wrote:
> Steve Borho a écrit :
> > On Tue, 2007-12-18 at 19:44 +0000, Paul Moore wrote:
> >> It looks like hg convert won't work for the Windows binary
> >> distribution, as that doesn't include the Python Subversion binaries.
> >> Does that seem right (or could I be using the command wrongly)?
> >>
> >> When I try, I get
> >>
> >>> hg convert http://lua4nt.googlecode.com/svn/trunk/ lua4nt-hg
> >> initializing destination lua4nt-hg repository
> >> abort: http://lua4nt.googlecode.com/svn/trunk/: unknown repository type
> >>
> >> Is it possible to enable conversion from Subversion with the Windows
> >> binary distribution, or do I need to build my own?
> >
> > I've been debating with myself over bundling the svn python bindings in
> > my Windows installers.  My main fear is that the setup is just untested.
> > I haven't heard many success stories of people doing svn->hg conversions
> > on Windows.

I tried a manual build and got what I'd describe as inconsistent
results at best. I can't recall the exact details now, I'd need to do
some more tests. However, I did finally get a version that worked,
insofar as it started the conversion.

> Most tests pass (http://hg.intevation.org/mercurial/pmezard/crew-
> w32.mq/file/tip/test.log) and it worked on my development repositories. I am no
> longer using it these days but I would be happy to investigate Windows related
> issues.

Thanks. I do use Windows, and I code in Python, so I'm happy to help
with diagnosis and (where I can) fixes. The problem here is that I
know nothing about the Python SVN bindings, so I don't really know
what *should* work.

> Convert runs without error on the supplied directory (not obvious with
> googlecode stuff).

Sorry, I don't follow you here. When I ran the conversion noted above,
using a self-built Mercurial with the Python SVN bindings available, I
got a Python exception from somewhere in the py-svn code (something
about pickle.dumps, if I recall, but it was very late and I didn't
print the stack trace).

Now that I've established that things should work, I'll try to produce
a better test case.

Regards,
Paul.

PS Would it be worth Mercurial adding an extra entry to sys.path,
maybe an "extralibs" subdirectory of the place where Mercurial is
installed? Then users could put additional libraries like pysvn in
there, even for the standalone binary build. It might make
distributing extensions easier.