What are the easiest/best methods for managing your ctags tag file(s)?

Question

I just started using ctags and greatly appreciate the tool but the way I manage my tag file is somewhat cumbersome in my opinion and very inflexible.

How I currently manage my tag file:

1. I have one monolithic tag file stored in my home folder at ~/.vim/tags
2. When I update my code or change projects I run a script that deletes the old tag file and regenerates the monolithic tag file (you have to change the location of where ctags executes from when you change projects)

Having one monolithic tag file works for me because it lets me jump to all the relevant symbols for the current project I am working on.

Would a single monolithic tag file will not work for a large/huge codebase? Why would a huge tag file not work on a large/huge codebase?

What are other ways to manage your tag file (or tag files plural)?

And why would your new method for managing your tag files be better? (Presumably a better solution would sometimes be more complex. So if your solution is more complex I am asking you what is the added benefit for a more complex method for managing your tag files.)

---

p.s. I found a stackoverflow question talking about ctags called "vimctags-tips-and-tricks" but this question doesn't talk about how to manage your tag files.

Answer 1

I put my tags file in the project directory. That keeps the tags separate for each project.

For large codebases, I just reduce the frequency at which I update it. I usually only update it if I try to jump to a keyword and it's not there for some reason. After all, the purpose is to quickly get to some other part of the code, and if it gets there by whatever means, then it worked even if the tag file is out of date.

Answer 2

Much like Greg, I keep the tag file in the project directory. I then use project plugin with it's in= tag to set up the tag file location and whether to use recursion when regenerating tags and cscope.out for different projects.

I usually only update the tags file when there have been significant changes as the tag will usually get you to the right line (or at least nearly the right line) even if it's out of date. The main reason I update is if I've added a new enum, struct or similar and I want the tag syntax highlighting to be updated.

Answer 3

One approach I've recently become fond of is using VCS (Version Control Systems) hooks to generate the ctags files. I use git locally even for small projects and such, and so the ctags gets updated every time I commit (this is, obviously, possible with all other VCS's out there).

I personally like to place the ctags file in each project's directory, but this approach should work just as well globally.

EDIT: VCS hooks are scripts or programs that run automatically when certain actions are performed, such as checkout, commit, revert and others.
For further reading I suggest the following links:

• Subversion: The Implementing Repository Hooks and Repository Hooks sections of the SVN book.
• Git: The Git Hooks section of the Git Community Book.
• Mercurial: The Handling repository events with hooks section from the online book Mercurial: The Definitive Guide.

Hooks are generally available in all VCS's I've bumped into, and I'm sure you'll be able to find documentation for the one you chose to use.