# Capstone version control: one working file, clear submissions

> **The short answer**: Capstone version control starts with one agreed working file and named milestones. Google documents use version history, while uploaded PDFs use separate file-version controls. Before restoring earlier work, preserve the current state or make a comparison copy so you do not discard a teammate’s valid changes.[^1][^2]

**Key takeaways**

- Publish one agreed link for everyday work.
- Distinguish native Google document history from uploaded file versions.[^2]
- Name milestones around reviews and submission.
- Compare an earlier copy before replacing shared work.

![Diagram: Working draft, Named milestone, Submitted export](https://tiswa.app/assets/blog/capstone-drive-version-control/cover-en.webp)

The group chat contains final, final-revised and final-after-review. The most recently sent attachment is not necessarily complete: one teammate corrected references in the first file while another updated results in the second. Capstone version control starts with an agreement about where the accepted work lives and who decides that a package is ready for submission. Filenames cannot settle those decisions on their own.

> **tiswa's take**: Keep a stable link for daily work and create separate copies deliberately. A new attachment for every punctuation change multiplies confusion. Independent copies are useful for experiments and archives, provided everyone knows they are outside the agreed working document.

## How does a working file differ from a submission package?

The working document changes throughout the week. A submission package records what you intended to send at a particular milestone. Put the working link, submission owner and naming rule somewhere the group actually checks. For example, report-supervisor-review-v01 and report-submission-v01 describe different purposes. These are suggested conventions, not university requirements; use the course’s required filename when one exists.

| Copy | Purpose | Who changes it |
|---|---|---|
| Working document | Combine ongoing writing and corrections | Authorised collaborators |
| Experiment | Try an alternative without disturbing the group | Person running the experiment |
| Review milestone | Record what was sent to the supervisor | Review owner after agreement |
| Submission package | Collect the exact file and appendices to upload | Submission owner |

An archive folder cannot explain why two versions differ. You need context: the supervisor changed the question, the dataset was corrected or a proposed rewrite was rejected. Add a short description at important milestones. “Revised variable definition” is more useful than “improved report.” That small note helps a teammate compare versions weeks later without reopening an entire chat history.

## How does Google Docs version history differ from Drive file versions?

Native Google documents have version history for inspecting earlier work, and viewing previous versions requires editing permission. An uploaded PDF, image or other file uses a different file-version system. Identify the file type before looking for recovery controls. A shared location in Drive does not make every file behave like a Google document.[^1][^2]

1. **Establish the working link**: Place it where everyone agrees to look. Label it as the accepted working document rather than another attachment to inspect.
2. **Mark a useful milestone**: After a chapter review or a supervisor submission, record a description that identifies the stage. Avoid repeatedly naming versions “updated.”
3. **Inspect the specific change**: Use document version history to locate the missing passage and relevant edits. Recover the smallest useful piece instead of replacing the entire report.[^1]
4. **Make a comparison copy**: Google allows a copy of an earlier document version. Compare that with current work before deciding what to restore.[^1]

![Workflow: Choose one source, Name a milestone, Export the submission, Check before restoring](https://tiswa.app/assets/blog/capstone-drive-version-control/workflow-en.webp)
Compare before replacing shared work.

## How do you recover a missing passage with Google Docs version history?

Imagine a team of four. You agree on a data-collection paragraph on Tuesday, then notice on Wednesday that it has disappeared. Restoring Tuesday’s whole document could remove a results table added on Wednesday morning. Open the earlier version separately, identify the paragraph and check whether its deletion was intentional. Then bring back only the agreed text. The example describes a team process, not automatic conflict resolution by Drive.

For a larger problem, ask the group to pause editing and name one person to compare versions. Preserve the current state before a broad change. After combining work, ask the results author to check the table and the methods author to check the paragraph. Recovery can restore bytes; the people responsible still need to decide whether the recovered content is correct.

## How should you name files without breaking links?

For uploaded files, choose a stable sequence such as project, document type, stage and version number. Avoid participant names or sensitive research details in filenames that will leave the group. Give appendices meaningful names too: appendix-a-survey matches a reference to Appendix A more clearly than scan-new. A short naming rule works best when everyone can apply it without consulting a long manual.

Do not rename linked assets inside analysis or design projects casually. Some applications depend on exact paths. Try a reorganisation on an experimental copy and reopen the project before applying it to the working folder. An elegant folder structure is no improvement if images or data links break just before submission. Document the change for the teammate who will open the project next.

![Checklist: One working link, Milestone identified, Upload type understood, Submission preserved](https://tiswa.app/assets/blog/capstone-drive-version-control/checklist-en.webp)
Review these points before the semester ends.

## Plan who retains the project

Ask early about university account continuity and project handover rules. Do not assume one member’s storage remains available to everyone after graduation. Decide who retains permitted copies, who reviews supervisor access and where the submitted package belongs. Sharing is not automatically an ownership transfer; permission roles have different capabilities.[^3] If the department owns or restricts the research material, its requirements determine the handover.

Use the [capstone permissions guide](https://tiswa.app/en/blog/capstone-drive-permissions/) to organise team access, [backup before repair](https://tiswa.app/en/blog/student-backup-before-repair/) to preserve work independently of a device and [student cloud storage](https://tiswa.app/en/blog/free-cloud-storage-students/) to compare storage options. These solve adjacent problems; a version history still does not replace a complete backup or a clear permissions policy.

The University of Michigan explicitly asks departing members to plan continuity and transfer university work to the appropriate recipient.[^4] That illustrates why institutional policy matters; it is not a rule for Saudi universities. Ask your own university which account services continue and which project materials you may retain.

Agree on the workflow before buying another subscription. When you need additional tools, check [student discounts in Saudi Arabia](https://tiswa.app/en/deals/). [Browse student deals](https://tiswa.app/en/join/)

Before uploading the final assignment, open the exact package you intend to submit. Check filenames, appendix numbering and the appearance of Arabic text and tables in the exported PDF. After upload, keep the platform’s submission confirmation alongside that package. A correct document in Drive is evidence that the document exists, not evidence that the same document reached the assignment submission box.

## Questions

### Do we need a new copy after every edit?

No. Use the working document and its history, with separate packages for meaningful milestones.

### Is Google Docs version history the same as Drive PDF versions?

No. Native document history differs from version controls for files uploaded to Drive.[^2]

### Should I restore an earlier version in Google Docs immediately?

Compare it and preserve current work first, because current work may include valid changes you need.

### Why is Google Docs version history unavailable or greyed out?

Check your access first: Google requires editing permission to browse earlier document versions. Open the intended account and file before requesting more access. This check does not diagnose every possible interface issue.[^1]

### What should the final copy be called?

Use the course requirement when provided. Otherwise agree on a consistent name identifying the project, submission stage and version.


## Sources

[^1]: Google Docs: find changes and earlier versions, https://support.google.com/docs/answer/190843?hl=en
[^2]: Google Drive: activity and file versions, https://support.google.com/drive/answer/2409045?hl=en
[^3]: Google: share files and permission roles, https://support.google.com/docs/answer/2494822?hl=en
[^4]: University of Michigan: Google storage and departure planning, https://its.umich.edu/communication/collaboration/google/storage-management