26
\$\begingroup\$

It occurred to me the possibility that while, for example the game engine, is being worked on simultaneously by multiple people how is overwriting prevented?

Let's say developer one is working on Audio.cpp and developer two is also working on Audio.cpp, how is this generally managed in large teams to combat overwriting? (In other words to stop developer two from opening the file until developer one is finished)

\$\endgroup\$
3
  • 84
    \$\begingroup\$ One of the tags you selected is already the answer. \$\endgroup\$
    – Philipp
    Commented Jan 11, 2015 at 16:52
  • 18
    \$\begingroup\$ In fact, 3 of the 4 tags are an answer, but one is the answer. \$\endgroup\$
    – MSalters
    Commented Jan 12, 2015 at 16:54
  • 1
    \$\begingroup\$ Related: gamedev.stackexchange.com/q/480 \$\endgroup\$
    – moooeeeep
    Commented Jan 13, 2015 at 18:33

3 Answers 3

Reset to default
69
\$\begingroup\$

Most software development teams (not just in game development) solve this issue using version control software. Examples are

All these tools have some differences, but the basic workflow is usually like this: There is one central repository for the project with the complete codebase. When a developer wants to join the project, they perform a "checkout". The version control software copies the codebase to their local machine. The software remembers the current version ("revision") of the codebase. When a developer made their changes and wants to put them onto the main repository, they perform a "commit". Their changes are uploaded to the central repository, and a new revision number is created.

When another developer now wants to commit their changes but the revision they once checked out is no longer the most recent one, the version control system won't let them. The developer first needs to "pull" the revisions which happened in the meantime. This updates their local copy to the most recent version on the central repository. When there are conflicts (intermediate revisions made changes to a file they also changed), the software might ask them to resolve the conflict by editing the conflicting files manually (a "merge") in case it doesn't manage to automatically do that. After they have done that, they can commit their changes as a new revision.

\$\endgroup\$
4
  • 18
    \$\begingroup\$ Note that Git and Mercurial are distributed version control systems, which work a little differently: they don't require a single central repository, but theoretically allow any developer to pull updates directly from anyone else. Of course, in practice, it's still common to have one repository (often located on a public host like GitHub) declared the "official" one, and used more or less like the central repository in a non-distributed version control system. \$\endgroup\$
    – Ilmari Karonen
    Commented Jan 11, 2015 at 18:24
  • 18
    \$\begingroup\$ This answer also implies that merging is always done manually. Most of the time however the version control software can merge differences automatically, and only require manual work for really thorny changes. \$\endgroup\$
    – jhocking
    Commented Jan 11, 2015 at 19:21
  • \$\begingroup\$ Please avoid extended discussion in comments, folks. This isn't a discussion forum. Use the Game Development Chat if you want to do that. I've cleaned up several tangential comment threads. \$\endgroup\$
    – user1430
    Commented Jan 13, 2015 at 16:48
  • \$\begingroup\$ Also, ideally each team member would be in charge of specific modules almost exclusively, and only in rare cases more than one person would modify the same source file within a short period of time, as this workflow minimizes the need to merge conflicting changes. But that is not always the case. \$\endgroup\$
    – Nicolas Miari
    Commented Jan 14, 2015 at 14:51
13
\$\begingroup\$

Developers don't use the same file.

Each developer has his own version of the file, and they use a special kind of software to manage their work. If they both make changes to it, the one that tries to overwrite the changes done by the other developer will encounter a conflict which must be resolved, otherwise the software I talked about starts complaining. In other words, the developer that causes the conflict, needs to combine their work with the other developer's work, and only then can the file be "saved".

This is a simple explanation for a part of the otherwise not so simple concept of version control.

\$\endgroup\$
1
  • 6
    \$\begingroup\$ Also they do this novel thing called communicating and software isn't written in a vacuum. So if they don't understand the conflict, they go talk to the other person or coordinate beforehand. \$\endgroup\$
    – Engineer2021
    Commented Jan 12, 2015 at 21:15
9
\$\begingroup\$

In addition to the points raised in the other answers about version control and handling conflicts with merges, there are at least two other ways that team members can avoid overwriting each other's work:

  • Some version control systems (e.g. SVN) allow locking of files. This means that one team member can take exclusive ownership of a file for some length of time, preventing other team members from making conflicting edits (or, really, any edits) until the file is subsequently unlocked.

    However, this is generally used infrequently, as it can cause a number of problems. It can reduce productivity (by limiting who can work on files at any particular time), and can cause problems if someone forgets to unlock a file. Also, at least for SVN (I'm not sure about other VCSs), locking a file doesn't prevent someone else making changes to their working copy, it only prevents them committing their changes - this can result in wasted effort if a developer modifies the file only to discover they can't commit their changes because it is locked.

  • Teams can try to assign tasks to developers in such a way that they don't have more than one person working on any particular file at a given time. For example, developers could each be responsible for a particular part of the project (e.g. 3D rendering, network, audio, etc) - if the codebase is well modularised, then the developer assigned to the network code should have little need to touch the files dealing with audio.

    Of course, there will always be some overlap that must be managed some other way.

\$\endgroup\$
10
  • 2
    \$\begingroup\$ On the plus side, locking is about the only way you can edit a .JPEG or other non-plain-text file. This isn't a theoretical limitation, it's just that the merge tools usually suck. \$\endgroup\$
    – MSalters
    Commented Jan 12, 2015 at 16:56
  • 2
    \$\begingroup\$ @MSalters It's not that the tools suck, it's just that most of the merge tools are created for text, not for binary data. And how would you resolve a conflict if two changes modified the same pixel in a file? Or even worse, how would you factor in the changes caused by JPEG compression? It's a very complex issue which might not even have a single good solution, so the reason most merge tools don't support is because the need for that is very rare and the functionality difficult to implement. \$\endgroup\$
    – Maurycy
    Commented Jan 13, 2015 at 10:50
  • 3
    \$\begingroup\$ @MaurycyZarzycki: Changing the same letter is similar to changing the same pixel: that needs manual resolving. .JPEG probably was a bad example, I now realize, because artists don't work on lossy formats. But the merge issue also exists with .PNG. At the very least, you'd appreciate if merge tools would be able to merge XML without breaking it. \$\endgroup\$
    – MSalters
    Commented Jan 13, 2015 at 10:57
  • \$\begingroup\$ @MSalters Sure, with that I can agree much more. \$\endgroup\$
    – Maurycy
    Commented Jan 13, 2015 at 11:14
  • 1
    \$\begingroup\$ @xorsyst: Try it this way: check out from SVN in two locations. Then lock a file from location 1. Location 2 won't know it is locked until commit or update. \$\endgroup\$
    – Zan Lynx
    Commented Jan 14, 2015 at 19:54

Not the answer you're looking for? Browse other questions tagged .