On Mon, Sep 12, 2011 at 17:14, Philipp A.
thanks for picking up my rant in such a constructive manner :)
A quick googling showed me this tool, cvs2git, whose “Development status” section really sounds promising:
~~~~
Development status
Most of the work of converting a repository from CVS to a more modern version control system is inferring the most likely history given the incomplete information that CVS records. cvs2svn has a long history of making sense of even the most convoluted CVS repositories, and cvs2git uses this same machinery. Therefore, cvs2git inherits the robustness and many of the features of cvs2svn. cvs2svn can convert just about every CVS repository we have ever seen, and includes a plethora of options for customizing your conversion.
The output of cvs2git is one or more dump files that can be imported into git using the excellent git fast-import tool.
Although cvs2git is considerably newer than cvs2svn, and much less well tested, it is believed that cvs2git can (cautiously) be used for production conversions. If you use cvs2git, please let us know how it worked for you!
At the moment I'm using git cvsimport -C $DIR/git/gnuplot.git -p x -d $DIR/cvs/gnuplot gnuplot to get gnuplot out of CVS repository. So far this worked reliably, the only problems that I experienced were: - I forgot the --delete switch when using rsync to fetch files from CVS repository, so files were not removed from repository, but that was entirely my fault - I once deleted a directory in CVS which had disastrous consequences since all the files from that directory are lost. But I think that this is a limitation of CVS, not limitation of git import tool. Nobody could restore those files. I had the git repository from an earlier attempt, so this was not a problem, but the CVS repository is still of questionable value. - files in CVS repositories on sourceforge have utterly weird permissions (like 575 for example); when I do "git cvsimport" those permissions stay on files on the same computer, but since git doesn't keep exact permissions, it turns out to be ok at the end - Warning: commit message does not conform to UTF-8. You may want to amend it after fixing the message, or set the config variable i18n.commitencoding to the encoding your project uses. Apart from that, no negative experience.
~~~~
I hope this means that PGF/TikZ becomes hosted on Github – I think the team there does a great job and the concept of “pull requests” really fits any open source project, no matter how hard the criteria for patches are.
Sadly not. If I put their code to GitHub, this doesn't mean that GitHub will become their primary version control system. I would use it just to simplify packaging of ConTeXt distribution. However: - it would be a convenient place for pgf developers to see which patches are needed - patches would be tested by ConTeXt users - it would be much easier to keep track of changes that are needed - we could use the bug tracker to keep track of changes that are still needed - Aditya or anyone else would be free to play with more ConTeXt-like code; pgf developers are not all aware of modern coding style in ConTeXt, but if they received a ready solution, they might accept it I have now put the files to https://github.com/mojca/pgf The location is temporary, so don't rely on it. Here is what I did: rsync -aO --delete rsync://pgf.cvs.sourceforge.net/cvsroot/pgf/ cvs/pgf git cvsimport -C $PWD/git/pgf.git -p x -d $PWD/cvs/pgf pgf git remote add origin git@github.com:mojca/pgf.git git push -u origin master git push --tags The main problem is that I'm not yet sure how to transform this into TDS (keeping all the history etc.) Mojca