Open main menu

CDOT Wiki β

Changes

Code Indexer

2,141 bytes added, 00:22, 9 November 2006
m
Options
==Options==
* Help with [http://lxr.mozilla.org/ LXR]/[http://landfill.mozilla.org/mxr-test/ MXR]/[http://www.mozilla.org/bonsai.html Bonsai] development.
* Make a sort-of branch respectful version of [[OpenGrok]]but this would be a very shoddy implementation that doesn't really do what it should* Setup one OpenGrok per active branch of the Mozilla Project, this would have no version history whatsoever, apart from file dates.
* [Re]write major portions of how [[OpenGrok]] deals with history and changesets and the likes, this is my personal preference.
* Try to fit [http://www.cenqua.com/fisheye/index.html Fisheye] into the current development model, but it seems this might be more like finding a problem for a solution. That This is a very very powerful tool, but it is not really like LXR or OpenGrok, it is more useful to say analyze CVS/SVN histories more than search for functions, files, definitions and the likes.  ====Why I like OpenGrok====Apart from the fact that it does not support branches, this is in my opinion the perfect tool. It is fast, open souce and most importantly, it makes really easy to navigate, well thought out pages that just work. Because of the way OpenSolaris does file versions for their code, they don't use branches at all. OpenSolaris currently uses a linear method of file versioning, they don't use branches, they use versions as a sory of branch, basically the idea that Office 12 is the "2007 branch" and Office 11 is the "2003 branch". Mozilla doesn't do this, so it would be nessecary to implement this feature. Luckily, however, OpenGrok is very good toolmodularized and atomic in nature. If you go to the OpenGrok page, you can get a more complete explanation, but the basic jist of it is that there are many "Guru's", each with a task. The files are first read by the History Guru who looks at the file and decides what type of versioning the file uses. Once the versions have been analyzed, they are passed on to the file analyzer guru who then decides what type of file it is, and passes it on to a file type analyzer. The allows for portions of the code to be changed without changing the whole system, so if we wanted to be able to do special things with XUL/XPCOM as far as how to handle its symbols, we would write one module which is not dependent at all on any other file analyzer. The same way, if Mozilla switchs to SVN, we would just port the branching support to SVN. On the chances that Mozilla switches to something other than CVS or SVN, a HistoryGuru could be written for that type of versioning history. In closing, I really like the OpenGrok project because it is '''very''' fast, '''very''' powerful and '''VERY''' modular!
==Links==
1
edit