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.git
I'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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
