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?

  • 1
    Don't know about any Eclipse plug-ins... it sounds more like a job for the version control system. Sep 19, 2011 at 8:14
  • Why do you want to prevent that? Is it to avoid complications (bugs) or to save developer time? The solution depends very much on the answer to this IMO. Sep 19, 2011 at 10:50
  • Why don't you try some SVN, Apache Subversion or Tortoise svn will be fine for this.
    – user37017
    Sep 19, 2011 at 21:16
  • 1
    Why do twenty teams edit the same source?
    – user1249
    Sep 19, 2011 at 22:02
  • We have a VCS. We just changed from ClearCase to Git. Sep 27, 2011 at 8:14

7 Answers 7


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.

  • Most changes a vertical; modifies GUI, network protocols, database, the works. We need a tool to help us communicate refactorings. We try to refactor the code on every check-in to improve readability and reduce cost of maintenance. Sep 27, 2011 at 8:19
  • @RogerWernersson - I understand, I just don't think there is a good way to accomplish this. That's why my answer recommended structuring teams and responsibilities and the company culture so that toe-stepping is minimised as a result. Attempting to retro-fit a concurrent checkout on top of git is going to be painful, and probably have all the drawbacks of a centralised revision control system. I'm sure someone's done it though, you should be able to find some specific implementations, now that you have mentioned you are using git.
    – Daniel B
    Sep 27, 2011 at 9:01
  1. Ensure developers are assigned specific modules.
  2. Have a task/bug tracking system that tracks every refactoring change. Assign each issue to only one developer
  3. Some version control systems have the ability to lock a file so that only one developer can have update rights over the file. I have never used that feature but if developers are constantly stepping over each other, this is something you may want to consider.
  4. Have unit tests so that even if developers work on the same file, you know their changes don't break the app in any way.
  5. All of the above would help if your refactoring is contained within modules. However, if someone does a refactoring on a cross-cutting concern such as logging or security, it will affect many files by definition. Those need to be handled with care especially if you have not taken advantage of aop approaches already.
  • I am in favour of using locks in principle, but what to do if your tool (e.g. Eclipse) changes many files automatically through a refactoring. Should all changed files be locked automatically? The number of locked files could grow very fast. Should the locks be acquired incrementally? How to handle deadlocks?
    – Giorgio
    Sep 19, 2011 at 13:31
  • If you change a method signature and it affects many files, you have to acquire a lock on all the files. In case, someone else has a lock, you can acquire the lock forcibly (svn allows this) if your refactoring is higher priority.
    – Sriram
    Sep 20, 2011 at 4:01
  • Can this be automated (by storing priorities and resolving lock conflicts automatically)? Or each developer decides whether their refactoring has higher priority?
    – Giorgio
    Sep 20, 2011 at 5:38
  • I guess if the priorities are stored in the task mgmt app with a decent api, you could automate it. I've never tried it but I don't see why that should not be possible.
    – Sriram
    Sep 20, 2011 at 7:13
  • I don't want to raise a bug for each refactoring. The approach is to clean up code you change. Filing a bug report for each file sounds like too much work. Sep 27, 2011 at 8:23

There are/were version control systems that make developers checkout code before they can edit but these have there own set of problems. Better practice is to get developers to commit and update often. One developer could then mark a class as depreciated and commit then if the other developer updates before they start their refactor they will see the intent.

  • 3
    +1: Commit and update often also means that changes are small and easily manageable, making conflicts easier to manage.
    – Bringer128
    Sep 19, 2011 at 9:34
  • Commit often would help. Unfortunately, I can't change that. I'm looking for a tool to help us communicate. Sep 27, 2011 at 8:23

Technology cannot solve social problems. You need to get your developers to talk to each other and coordinate their work. With 20 teams, some structure and rules will be essential. You will want to support them with technological solutions, but people come first.

  • 3
    He spoke of 20 teams, not a team of 20.
    – Ingo
    Sep 19, 2011 at 10:26
  • 1
    +1 for technology cannot solve social problems. But do edit the answer to say "With 20 teams, some structure and rules will be essential"
    – MarkJ
    Sep 19, 2011 at 11:04
  • Some people sleep while others work. We have teams on four continents. Sep 27, 2011 at 8:24

If you leave notice that someone else is working on the same piece of code and talk to the first one before modifying anything, as per what you said, you need a version control system (CVS/SVN/GIT). I'm not sure though, but if you want to include that too, you will need some advanced things (some sort of triggering mechanism/some custom thing maybe).

  • We've got Git. Before that we had ClearCase. VCS is not the solution. We do need some triggering mechanism. Sep 27, 2011 at 8:30

Developers locking files in source control should solve your problem easily, but then I think you might have bigger problems.

4.5 Million LOC's is a massive sandbox to play in so in a well architected and designed solution you should rarely run into a situation where multiple teams of developers are stepping on each others toes. The fact that this happens more than coincidentally is telling of a some serious potential design flaws that should be looked into.

  • Most changes are vertical; GUI, network protocols, database. Each team is agile and focused on delivering customer value at every sprint. We can't have one team on database, one on GUI, etc. It would be easier if the code was cleaner. But the road to clean code is spelled "many small refactorings". Sep 27, 2011 at 8:26

A few things:

  1. Separate modules to work-on
  2. Talking about changes before they are made [with all devs]
  3. Unit testing [for verification and avoidance for breaking related things]
  4. As the others mentioned a VCS
  • 1. hard when each team works vertically 2. hard because some teams sleep while others work 3. doesn't address the issue 4. Where on Git now, previously on ClearCase. Sep 27, 2011 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.