views:

161

answers:

4

When using the merge tracking feature in Subversion 1.5, SVN updates the mergeinfo property of the parent folder to track the revisions being merged. We have a large number of developers (>500) working on our repository, and it is not uncommon around deadlines to have large numbers of developers all trying to commit around the same time. If some other developer has committed to the same folder since your last update, you are forced to update before committing due to the change in the mergeinfo. So how do you prevent the situation where a developer is forced to repeatedly update their working copy because each time they update, someone else commits to that folder before they do? Or is it rare enough of a situation that people just put up with it?

A: 

There is no solution to this problem other than:

  • Switch to GIT :) (or hg)
  • Putting up with it as you suggested.
CtlAltDel
With this many developers, git/hg doesn't solve the problem, it just masks the symptoms at commit time. See my answer for details.
Quinn Taylor
+3  A: 

We use SVN Notifier (Windows only) which sits in your taskbar and alerts you whenever a watched repository changes. This is the best way to avoid nightmare merges - if you update as soon as another person commits then merges should be quite easy..

Mark Pim
+1  A: 

Work on the decomposition of your project. Partition the system in subsystems and components and give each component a dedicated folder in source conrol.

Hundreds of developers working in the same folder seems like a managemenet nightmare, not only because of these svn issues.

laalto
I totally agree. Lots of overlap in development effort is a sign of potential problems regardless of which SCM tool you're using. If possible, refactoring the code structure and/or organization can really help.
Quinn Taylor
+1  A: 

@CtrlAltDel, I call BS on suggesting that a DVCS of any flavor is a silver bullet for this problem. In this case, all you might succeed in doing is shifting the merge burden from commit time to integration time, which is arguably a far bigger headache. Now, instead of experiencing conflicts in real-time on a centralized repository, you have developers working on increasingly diverging code bases in their own distributed repositories. Cobbling them together into a single coherent (and working) product is non-trivial.

I think the solution of notifying developers of repository commits has real merit. If you're not Windows (and can't use SVN Notifier, as Mark suggests) I recommend updating an RSS feed each time a commit occurs. You can do this via a post-commit repository hook — examples abound online.

However, being notified when something changes anywhere in the repository can quickly become a distraction. For finer-grained RSS, I use WebSVN (you have to enable RSS). Basically, you can ask for an RSS feed for any repository path (file or directory) and it is dynamically generated/updated for you. You can refresh the RSS as often as you like, too — the last version is cached until a new revision is committed. There are a number of RSS readers on all platforms that can alert a developer of changes.

Quinn Taylor