I would like to prevent a situation where two developers refactor the same code simultaneously without talking about it first, probably using a tool of some kind, maybe an Eclipse plug-in. Can you help?
We've got 4.5 million lines of code, and more than 20 teams of developers on four continents.
Ideally I would like the second of the developers mentioned earlier to notice that someone else is working on the same piece of code and talk to the first one before modifying anything.
Do you know of a solution?
Best Answer
Many 2nd-generation source control systems work using a connected "checkout" which informs the server that you are intending to modify a file. Examples include TFS, SourceGear Vault, and many others. In this way, you can technically accomplish your requirement. As Adam Butler pointed out though, these types of tools come with their own issues (without getting into a lengthy debate - limited support for offline work, and generally counter-productive development workflow).
I would definitely suggest some kind of hierarchical approach to allocating the refactoring work. The developers could be logically grouped into sub-teams, each responsible for specific areas of the code. Depending on how you like to structure teams, each one could have a "lead" role who is responsible for the high-level design of the team's area. This structure should be well-known to the developers, and it should simplify communication for refactoring. I am sure that this approach seems too formal and backwards to some, but I think it is greatly preferable to having 20+ developers use a "free for all" approach to refactoring a large system. Some refactorings will take place on a high-level (e.g. how will module X communicate with module Y), in which case you will need people who can make calls at the appropriate level. Not every developer in the team should be making architectural decisions, so a hierarchy is almost imposed in any case, even if one chooses to be ignorant of it.
So basically, there are tools to meet the basic requirement you put forth, but no tool is going to replace proper communications and having a small number of people driving the general architecture of your project.