Stefano Zacchiroli a écrit :
I delved into OCaml packaging svn history and decided it was too complex for a fully automated conversion keeping all the DAG-ish history. Therefore, I modified my svn2git script so that it generates shell scripts from "svn log" (XML) output. I then tuned the shell scripts for this specific packaging.Can I conclude from this summary that this remark is specific for the "ocaml" package?
Yes. I think packages that have (or had) branches will require manual operation. FYI, OCaml has branches, merges, merges from other parts of the svn tree, tags in various simultaneous branches, evolving layout since 2003... Packages with more complex history might need more time to migrate ;-)
http://git.debian.org/?p=users/glondu-guest/test/ocaml.git I believe this repository is ready for use.It looks nice, I'm in favor of using it and dropping svn OCaml history.
I've put it in: http://git.debian.org/?p=pkg-ocaml-maint/packages/ocaml.gitI've added usual hooks, and performed some (basic) changes in the package to reflect this new location.
Yes, thanks, though I think I've lost my memory about that, so it is probably useless :-), but I'll look into it and possibly delete by myself ... actually, the good choice is probably to move it as a repository called "zack/new-ocaml-md5sum" (which is a good naming convention for development branch until they are unleashed).
You mean a repository in /git/pkg-ocaml-maint/zack/...? Or in your own home? Or in a branch zack/... inside our main repository? If we are really concerned about disk space, the latter would be the better. If not, maybe using a separate repository would be better, so that everyone is not bothered with everyone's experiments. Of course, the point of git is to enable anyone to develop his own branch in his own repository.
* I intend to cleanup my svn2git script so that it generates a shell script for any package repos. The generated-shell-script method proved to be very flexible and useful for repos with complex branching/merging history. Moreover, one can more easily put breakpoints and make checks during the conversion process.Is it worth? I mean, the former version of your svn2git was "good enough" to handle most of our repositories, didn't it? [...]
It was, but my new approach parsing verbose output of svn log allows to detect possible issues without starting the svn-update/git-commit loop. Issues can be spotted faster in this way, so I think it is worth...
-- Stéphane