Work clarity
Which File Is the Current Version? Check Before You Edit
Published by OneCell
To find the current version of a file, start with what you need it for and the last agreed handoff. Compare the actual contents of the plausible copies with the changes that should be present. A recent date, a higher version number or “final” in the name is a clue, not proof that a copy contains all the agreed work.
If different copies contain different valid changes, you may need a new working version before editing continues. Preserve those copies while the person responsible for the file resolves what belongs in it.
Decide whether you need current work or a past release
“Which file is right?” needs a purpose. If you are continuing an edit, look for the working source that contains the agreed changes so far. If you need the image used in last month’s announcement, look for the exact output that was sent or approved for that announcement. Today’s working source may have changed since then.
Use the relevant handoff message, approval record or released attachment to identify that past output. If the record or file is missing, ask for that specific item. Choosing a similar-looking file does not establish which one was released.
Gather the plausible copies without replacing them
Find the last agreed source and the copies that may contain later edits. Check the existing working folder, relevant attachments and shared links. Keep track of where each candidate came from and who supplied it; two files with the same name may still be different copies.
Open them for comparison without overwriting the candidates. Bring the relevant change requests and handoff messages alongside them. Ask which changes were agreed and which file each person edited. If someone says “use the latest,” ask them to identify the exact file or link.
If you cannot open a candidate or reach the handoff record, leave that gap explicit. Ask for access or the missing file before treating your comparison as complete. This process cannot recover material you do not have.
Compare three files against the agreed changes
Consider a fictional shop updating a product photo. The last confirmed baseline is mug-v02.tif. The shop has agreed two changes for the next working image: a tighter crop and a color correction. Both changes belong in it.
The editor finds three candidates. These are invented observations for the example, not results from tested image files:
Confirmed baseline —
mug-v02.tif: The file in the last handoff thread has the earlier crop and color. It provides a reference for comparison but contains neither update.Crop change —
mug-v03.tif: The local working copy has the agreed tighter crop, with the baseline color. Preserve it because it contains one valid change.Color change —
mug-final.tif: The collaborator’s attachment has the agreed color correction, with the baseline crop. Preserve it too. Its name does not establish that it includes the crop change.
Neither updated copy contains both changes. Picking mug-v03.tif drops the color correction; picking mug-final.tif drops the tighter crop. Sorting those files by date would not supply the missing change.
Have one person produce the next working source
Ask the editor responsible for this image to produce a working version containing both agreed changes, using the existing editing process. Give them both candidate files and the messages identifying the changes. Do not assume the edits can be transferred automatically or without losing anything else.
The editor may need additional source material or clarification to reproduce a change. Keep the task unresolved until that input is available; renaming a candidate would not make it complete.
Suppose the editor produces mug-v04.tif. Compare that actual image with both candidates for the agreed crop and color, and confirm with the responsible editor that it is the source to continue from. The filename is just this example’s convention. It does not perform those checks.
Then record the handoff in the existing thread, using the actual location:
Continue editing from mug-v04.tif in the Product photos working folder. It contains the agreed tighter crop from mug-v03 and color correction from mug-final. Please use this file for the next edit; keep the earlier candidates available as references.
Use that wording only after those contents and the working location have been confirmed. Retain the useful source candidates and change record while the work is being reconciled.
Change the decision if an edit was only proposed
Now change one assumption: the color correction in mug-final.tif was a proposal, and nobody agreed to use it. Its presence in a file does not settle the direction.
Ask the person responsible: Should the next working image use the color correction shown in mug-final.tif, or retain the color in mug-v03.tif? The tighter crop is already agreed.
Keep the proposed color edit separate until that choice is confirmed. Once it is settled, the editor can produce or identify the appropriate working source and record its location. The same three files now support a different next action because the instruction changed.
Make the next source easy to identify
For later handoffs, keep one clearly identified working location, the person responsible for incorporating changes, and a short note of what the current version contains. Update that note when the working source changes.
The University of Cambridge’s file organisation and version-control guidance recommends consistent naming, a record of changes and agreement on who identifies the final version. Apply those basics to the place you already work: point the next collaborator to the confirmed source and state what it is for.