The Two Versions of the Same File
Two students collaborate on a program. Student A works on a laptop and edits a file called game.py for three hours, adding a scoring function and fixing a collision bug. Student B, working from a shared drive copy downloaded the previous evening, also edits game.py, rewriting the input handling and reorganizing the main loop. When A uploads first, then B uploads, A's scoring function and collision fix are gone. A's three hours of work exist only in a local backup. The pair must recover the work and prevent a recurrence. Neither has used version control before, and the shared drive has no history.
1. Explain, in terms of what was stored where, why A's work disappeared. Distinguish this from a bug in the program itself.
Read the worked answer
This is a storage and coordination failure, not a code defect. Both students held full copies of game.py; the shared drive kept only the most recent upload. When B uploaded, the drive replaced the file wholesale with B's version, which was derived from the previous evening's copy and therefore never contained A's edits.
The key point: the shared drive stores one current state with no history and no merge. It cannot represent 'A's changes plus B's changes' - it can only hold one file. So the loss was structural: the system had no way to preserve both versions. A's local backup is the only surviving copy of that branch of work.
2. Describe a workflow that would have preserved both students' work, and explain which specific failure it prevents.
Read the worked answer
Use version control with separate branches and a merge step:
- Each student commits to their own branch, so neither overwrites the other's history.
- On integration, the system attempts to merge. Where both edited the same lines (input handling vs. main loop), it reports a conflict for a human to resolve rather than silently discarding one side.
- Every commit is retained, so any lost work can be recovered from history.
This prevents the specific failure - silent overwrite - by making integration explicit. It does not prevent all bugs: a merge can still be wrong if the humans resolve a conflict carelessly. But it converts an invisible data loss into a visible decision.
3. The pair also wants to avoid future collisions. Propose one process change and state one thing it does not solve.
Read the worked answer
Process change: smaller, more frequent commits and a short integration cadence (e.g., merge at least daily). Smaller changes mean smaller conflicts and faster recovery, and daily integration keeps the branches close enough that divergence stays manageable.
It does not solve semantic conflicts - two changes that are individually correct but interact badly (e.g., B's new input handling assumes a variable name A renamed). Those only surface through testing after merge. So version control plus frequent integration reduces the frequency and cost of collisions but does not eliminate the need to test the combined result.