TikZ bug fixing (git, minimals, ...)
(was: Latest betas break tikz matrix) On Mon, Sep 12, 2011 at 11:16, Philipp A. wrote:
Thank you both!
We should get the TikZ devs to accept patches already. does anyone know anyone who has CVS access?
See doc/generic/pgf/ChangeLog Christian Feuersaenger ludewich, users.sourceforge.net Christophe Jorssen cjorssen, users.sourceforge.net Jannis Pohlmann jannis, xfce.org Matthias Schulz ma.schulz, email.de ... (Dear Christian: I'm still waiting for a fix for something that I sent a while ago. This original thread "Latest betas break tikz matrix" is at http://www.ntg.nl/pipermail/ntg-context/2011/thread.html.) We definitely need some ConTeXt specific bug tracking with automatic email reminders for pgf developers to fix those bugs ;) ;) ;) In principle we could also create a git project, create a context branch, apply the fixes to it and use that one in ConTeXt minimals, hoping that PGF developers will pick them up. Now a question: - It is trivial to convert CVS project into GIT project (git cvs import ...) - It is trivial to rearrange the structure into TDS with a script (I simply use a few rsync commands) - I don't know how to combine both. Does anyone have some nice idea how to take the existing CVS project with complete history and make a TDS-compliang git project out of it (keeping all the history, authors, ... etc.) I also have commit rights for TeX Live, but I don't dare applying patches without having them applied upstream. If nothing else, that just postpones the problem to the time after PGF will release a new version and that one won't work. Mojca
thanks for picking up my rant in such a constructive manner :) A quick googling showed me this toolhttp://cvs2svn.tigris.org/cvs2git.html, 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 http://cvs2svn.tigris.org/features.html. 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-importhttp://www.kernel.org/pub/software/scm/git/docs/gitfast-import.htmltool. 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! ~~~~ 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. hopefully, philipp
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
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
Untested (but this is really simple code, so nothing should break) https://github.com/mojca/pgf/pull/1 Aditya
On Mon, Sep 12, 2011 at 17:14, Philipp A. wrote:
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!
I took a look at their webpage after reading that cvs2svn is capable of converting .cvsignore into svn properties. When I tried to do conversion from CVS, the .cvsignore files are the only leftovers that somehow bother me (I would really like to get rid of .cvsignore files and put some gitignore somewhere, without my commit being visible), but then I noticed that .cvsignore -> .gitignore conversion is still on TODO list. The other thing that would make me happy would be the ability to apply some hook to do some transformation of code before comitting to git (let's say that I would want to reencode files into UTF-8 or that I would want to move or rename some files before the actual commit). If you know a simple way to do this, please let me know. Mojca Mojca
hi mojca, do you want to swich from cvs to git or just create a git mirror
of the cvs repo? in the latter case, i’d be interested in why you don’t
swich to git entirely.
2011/9/13 Mojca Miklavec
When I tried to do conversion from CVS, the .cvsignore files are the only leftovers that somehow bother me (I would really like to get rid of .cvsignore files and put some gitignore somewhere, without my commit being visible), but then I noticed that .cvsignore -> .gitignore conversion is still on TODO list.
that cvs2git didn’t build it in makes me wonder what the big problem is. both use shell-style wildcards, both can be anywhere in the path and apply to that subpath, so there must be some hidden caveat… The other thing that would make me happy would be the ability to apply
some hook to do some transformation of code before comitting to git (let's say that I would want to reencode files into UTF-8 or that I would want to move or rename some files before the actual commit). If you know a simple way to do this, please let me know.
yes, there is such a thing. it is aptly named “pre-commit hook”: http://book.git-scm.com/5_git_hooks.html but since there are many settings in git (e.g. core.autocrlf for line endings), i’d guess there are some for encoding, too. i might be mistaken, though. Mojca
philipp
On Wed, Sep 14, 2011 at 11:08, Philipp A. wrote:
hi mojca, do you want to swich from cvs to git or just create a git mirror of the cvs repo?
Create a git mirror.
in the latter case, i’d be interested in why you don’t swich to git entirely.
Because I'm not the developer. That decision would have to be made in the team developing PGF. If they don't like svn/git or other tools, I cannot make decisions instead of them what they have to use.
When I tried to do conversion from CVS, the .cvsignore files are the only leftovers that somehow bother me (I would really like to get rid of .cvsignore files and put some gitignore somewhere, without my commit being visible), but then I noticed that .cvsignore -> .gitignore conversion is still on TODO list.
that cvs2git didn’t build it in makes me wonder what the big problem is.
I was testing only "git cvsimport" so far, but the homepage of cvs2svn claims that they don't support it yet (they are looking for developers to implement it). The main developer is not a git user.
The other thing that would make me happy would be the ability to apply some hook to do some transformation of code before comitting to git (let's say that I would want to reencode files into UTF-8 or that I would want to move or rename some files before the actual commit). If you know a simple way to do this, please let me know.
yes, there is such a thing. it is aptly named “pre-commit hook”: http://book.git-scm.com/5_git_hooks.html
Thank you. I will try to figure out if I can make it work in my scenario.
but since there are many settings in git (e.g. core.autocrlf for line endings), i’d guess there are some for encoding, too. i might be mistaken, though.
I'm not talking about encoding only. I would also like to reshuffle files (create TDS structure out of current repository of pgf). Mojca
On Mon, 12 Sep 2011, Mojca Miklavec wrote:
We definitely need some ConTeXt specific bug tracking with automatic email reminders for pgf developers to fix those bugs ;) ;) ;)
Another option is to rewrite all the code in $TEXMF/tex/context/pgf directory in a more ConTeXtist way. Mainly this means writing a catcode table (as my example showed) and enabling them in each file. One could also consider using the standard \startmodule ... \stopmodule tags around each module. I can do that rewrite, but someone else will need to test all the changes as I don't use pgf/tikz.
I also have commit rights for TeX Live, but I don't dare applying patches without having them applied upstream. If nothing else, that just postpones the problem to the time after PGF will release a new version and that one won't work.
Please don't do that. In the worst case, it will be better to release a module with the different name rather than silently overwriting PGF files. Aditya
participants (3)
-
Aditya Mahajan -
Mojca Miklavec -
Philipp A.