[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A git repository for OCaml packaging...

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 ;-)


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:


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...


Reply to: