Oh boy, here we go. ;) I second Richard's suggestion to use cscope or some equivalent. It's a good idea in general, but especially with a codebase as large and complex as Gluster's. I literally wouldn't be able to do my job without it. I also have a set of bash/zsh aliases that will regenerate the cscope database after any git action, so I rarely have to do it myself.
Another secondary tip is that in many cases anything you see in the code as "xyz_t" is actually "struct _xyz" so you can save a bit of time (in vim) with ":ta _xyz" instead of going through the meaningless typedef. Unfortunately we're not as consistent as we should be about this convention, but it mostly works. Some day I'll figure out the vim macro syntax enough to create a proper macro and binding for this shortcut. I should probably write a whole new blog post about gdb stuff. Here's one I wrote a while ago: http://pl.atyp.us/hekafs.org/index.php/2013/02/gdb-macros-for-glusterfs/ There's a lot more that could be done in this area. For example, adding loc_t or inode_t or fd_t would all be good exercises. On a more controversial note, I am opposed to the practice of doing "make install" on anything other than a transient VM/container. I've seen too many patches that were broken because they relied on "leftovers" in someone's source directory or elsewhere on the system from previous installs. On my test systems, I always build and install actual RPMs, to make sure new files are properly incorporated in to the configure/rpm system. One of these days I'll set it up so the test system even does a "git clone" (instead of rsync) from my real source tree to catch un-checked-in files as well. I'll probably think of more later, and will update here as I do. _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
