Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
Don't know about any Eclipse plug-ins... it sounds more like a job for the version control system. –  S.L. Barth Sep 19 '11 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. –  KaptajnKold Sep 19 '11 at 10:50
Why don't you try some SVN, Apache Subversion or Tortoise svn will be fine for this. –  user37017 Sep 19 '11 at 21:16
Why do twenty teams edit the same source? –  user1249 Sep 19 '11 at 22:02
We have a VCS. We just changed from ClearCase to Git. –  Roger Wernersson Sep 27 '11 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.

share|improve this answer
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. –  Roger Wernersson Sep 27 '11 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 '11 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.
share|improve this answer
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 '11 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 '11 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 '11 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 '11 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. –  Roger Wernersson Sep 27 '11 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.

share|improve this answer
+1: Commit and update often also means that changes are small and easily manageable, making conflicts easier to manage. –  Bringer128 Sep 19 '11 at 9:34
Commit often would help. Unfortunately, I can't change that. I'm looking for a tool to help us communicate. –  Roger Wernersson Sep 27 '11 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.

share|improve this answer
He spoke of 20 teams, not a team of 20. –  Ingo Sep 19 '11 at 10:26
+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 '11 at 11:04
Some people sleep while others work. We have teams on four continents. –  Roger Wernersson Sep 27 '11 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).

share|improve this answer
We've got Git. Before that we had ClearCase. VCS is not the solution. We do need some triggering mechanism. –  Roger Wernersson Sep 27 '11 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.

share|improve this answer
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". –  Roger Wernersson Sep 27 '11 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
share|improve this answer
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. –  Roger Wernersson Sep 27 '11 at 8:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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