|
Size: 2918
Comment: some ideas how to improve hg
|
Size: 284
Comment: Add CategoryHomepage.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| We currently use GNU Arch for our MoinMoin repository, but after some playing with mercurial and having a working converter, who knows... - I like good Python programs. :) | We used CVS and GNU Arch for our MoinMoin repository, but switched to Mercurial because it is so nice and fast (and mostly in Python). |
| Line 7: | Line 7: |
| = How to improve Mercurial = I am new to hg, so take this with a grain of salt. I am willing to do some of that stuff listed below, but I hesitate to do bigger refactorings / src code reformatting as long as I don't know if this is wanted by core developer(s). == general stuff == * run pychecker more often - although it might give some false alarms, it often points out strange places in the src and sometimes even severe errors. * read and follow pep-0008 and maybe put multiple statements on multiple lines (even for single line blocks under some "if"), makes it more readable * make sure every py src code file begins like: {{{ #!/usr/bin/env python (optional, for tools) # -*- coding: iso-8859-1 -*- (or ascii or utf-8, just to make things clear) """ What this file does in a single line. What this file does in some more detailed description... @license: GNU GPL, see COPYING for details. @copyright: 2005 Firstname Lastname <email> @copyright: 2005 more authors... """ }}} This stuff could be put into some _template.py so one can easily use it when starting a new file. * Avoid putting longer license texts ONLY into the header of src files - nothing is more boring and annyoing when you try to find out what some file does. I personally like to reference licenses ''by reference'' (see above), that's shorter and leaves more space for useful "what this does" comments. I am not a lawyer... * make sure your src code files end with an empty line (makes it easier for diff, avoids "missing end of line at eof warnings") * use more epydoc docstrings and generate docs using epydoc tool, put the html output somewhere online == optimizing for portability == hg is optimized for speed mostly. With Python it uses a highly portable language, though. In some applications (like making a hg moin 2.0 backend some time in the future), extremely high speed is less important, but if one demands a C compiler for installation, this can cause trouble for installation. Even if you compile it before and offer platform-dependent packages, it loads the developers and maintainers with the burden to make such platform dependend packages. As this only affects mpatch.c and bdiff.c, I would be glad so see some python equivalents of them and import code similar to: {{{ try: import c_bdiff as bdiff except ImportError: import bdiff }}} I didn't try what setup.py install does right now when there is no C compiler, but as soon as we have the py implementations it should only emit some warning "No C compiler found, using py implementations...". |
CategoryHomepage |
I am a MoinMoin wiki developer (also in Python) and Linux user.
See ThomasWaldmann and ThomasWaldmann.
We used CVS and GNU Arch for our MoinMoin repository, but switched to Mercurial because it is so nice and fast (and mostly in Python).