ANN: yasvn2hg -- yet another SVN to HG converter

Daniel Holth dholth at fastmail.fm
Tue May 1 04:10:07 UTC 2007


On Mon, 30 Apr 2007 12:05:12 +0200, "Patrick Mézard" <pmezard at gmail.com>
said:
> Daniel Holth a écrit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Joel Rosdahl wrote:
> >> Matt Mackall <mpm at selenic.com> writes:
> >>
> >>> [...]
> >>> Did you add this to the wiki?
> >> Yep.
> > I count at least 5 tools for converting to-and-from SVN <-->
> > Mercurial. Why don't we get together, merge the best features from
> > these projects, and build something that works great? There's surely
> > enough source material...
> 
> +1
> 
> [...]
> 
> > Features that would be nice (queue-convert-svn has features marked
> > with *):
> 
> It looks like people are rewriting converters because every single 
> repository out there has its very own set of complications. Maybe a good 
> starting point would be to create an ugly monster from all these SVN 
> repositories (or even better, scripts to generate monsters at will) and 
> test the tools on it. It would clarify the situation and be reusable by 
> other conversion (non-hg related) projects.
> 
> --
> Patrick Mézard
> 

Edouard,

I will look at your changes.

Patrick,

That's more or less true. I wrote my converter because Tailor was very
slow, and because it failed around revision 6,000 of 10,000. I kept
working on it because I needed copy-from information to merge correctly,
and then I stopped because I was done converting. But I'm very
disappointed that I can't convert The Subversion Repository anymore.  I
would be happy to work with someone else to fix some of the bugs in my
converter (mostly it needs to get the log in chunks, and deal with
copy-directory-and-delete-file-in-directory) or help someone else to
understand the SVN api.

I saw some funny stuff in some of the other scripts "check out
random-svn-repository at 4503 for a weird case" etc. We can run
Subversion's own regression tests and tell them not to clean up, but we
can also generate all the challenging cases (with small files) and use
"svndump" to provide a convenient, less-than-348-megabyte (The
Subversion Repository) test corpus. I have my own little test case
already. There are even some more tricky things that can happen in a
Subversion repository, but can only be done to it with the API (not with
working copy manipulations followed by commit).

Thanks,

Daniel




More information about the Mercurial-devel mailing list