In software it is a best practice to store the source code in Version Control software (also called VC, Configuration Management or CM, SCM for Software CM). This lets one go back and look at 1) changes to the code 2) prior versions of the code.

Since Microsoft Project files aren't text files, doing this directly doesn't help with looking at changes. Is there a good way to do this? I'm thinking perhaps export the project in a text format that can be compared.

EDIT: my goal is to answer questions such as "When did that used to be due?" and "That seemed to have changed; did I add or delete a dependancy"

  • 1
    I thought there was a "Compare Versions" functionality in MS Project (I don't have a copy in front of me) -- are you talking about something different (or am I remembering incorrectly)? – jcmeloni Feb 21 '12 at 22:59
  • 1
    @jcmeloni. That is from Project>Compare Projects, at least in the 2010 version. Trying that now. – Brian Carlton Feb 21 '12 at 23:08
  • 1
    I think it still needs specifically-saved files, not revisions within the files, so it might not be what you want. I was just going from memory. :) – jcmeloni Feb 21 '12 at 23:30

Short answer: I've configured Mercurial so when I ask it to do a binary diff (e.g. .docx) it uses docdiff to feed both versions to MS Word in compare mode--allowing me to see both revisions and the compared version of the document. It doesn't work for PPT because that POS program doesn't support comparison, but the other answers suggest Project does support comparison. Ostensibly, StackOverflow would be a good place to figure out how to properly configure Hg for comparing Project files.

Long answer on why I think VCS is a must, even when working with binaries

I've use Mercurial to store binary files (mostly MS Office). Version Control Systems may be at their best with text files because it's so easy to diff changes and so cheap to store deltas; nonetheless, I've found a VCS to be invaluable even for binary files.

Let me provide a couple of use cases:

  1. Working by yourself: If you're the only author of a file and no one else can access your folder, it isn't that hard to maintain a canonical version of a file and dump old versions into an archive folder neatly organized by filename.

    ground rules v01 20120102.mpp
    ground rules v02 20120102.mpp
    ground rules v03 20120105.mpp

    The downsides are that you have to be a little OCD to keep this up and there's no easily accessible record of what's change from version-to-version.

    If you put the same file in a VCS the commit comments can summarize what you changed. Obviously this isn't as precise as being able to see the diff, but it's remarkable how useful even a sentence or two will be in narrowing down exactly what version you're looking for.

  2. Working in a shared folder: This example will either sounds like an insane straw-man or you'll be nodding your head in silent commiseration. Absent a version control system, yet still gripped by fear of throwing away data, binary files in a shared folder proliferate like bacteria in a petri dish.

    Fileserver hell

    Truly solving this problem requires a cultural change on your team, but you can do a lot better even if you're the only one using the VCS. I keep a repo locally, manually merge changes from multiple sources, check in revisions, and clone the repo to the server. It keeps the folder clean and all the old stuff can always be retrieved quickly thanks to the meta-data. The best part is no one even has to know it's a VCS; they just see a clean folder with an obviously current version of the file.

    Unfortunately the merging is done manually, but that's a curse of binary formats without merge-tool support (and why I advocate moving away from them to marked-up text for documentation). (Not really an option for MS project files though.)

    Another nice thing about this workflow is that because Hg tracks changesets and not revisions, people can edit different files all they want, and you can even check them in directly on the server repo. As long as the changesets don't stomp on the same binaries they'll pull and merge into your local repo no sweat.

Bottom line is there may be a way to configure Hg or some other VCS to push two versions of the same .mpp file into project so you can compare the changes, but even if not, the benefits of storing the binaries in a VCS are incomparable, and with the good use of commit comments you should see a significant benefit.


EDIT: my goal is to answer questions such as "When did that used to be due?" and "That seemed to have changed; did I add or delete a dependancy"

Just for the the first question I think using the baseline feature of Microsoft Project would help. You can create baselines to take snapshots of the project schedule over time. I have actually never used this feature but I think it is what you are after.


Project files are big, bulky and opaque.

Version control systems work best on text files and so versioning something like Project or Word files will usually work poorly.

I think it's worth stepping back and considering what exactly it is you are trying to do. Why do you want to look at historical versions of a file? Is seeing an earlier version going to help you in a meaningful way? You should probably be looking at tools which can generate historical reports rather than trying to do some visual comparison of a Project file. It will save you a ton of time.


Maybe you are comparing apples & oranges. Source code is worked on by many different people on different parts concurrently in a fairly dynamic manner. A project plan (including budget, schedule, scope statement, risk manaegment plan etc etc) should be reviewed and changed in a controlled manner by a relatively limited number of people. So there should be documentation of the approved changes made at least at a high level outside of Project (e.g. project plan review meeting minutes, exception plan documentation, etc).

Beyond that, one thing that I've found helpful to keep track of what I've done to a schedule in Project is to use the "Notes" section for each task changed to document what changes were made, who made them, and date they were made.


If you took periodic baselines, you can see the task variations side by side in the Tracking Gantt view. However, in a complicated project, that could get very confusing, very quickly.

  • This was my second best answer. This would work well if you don't have too frequent changes. – Brian Carlton Apr 12 '12 at 18:29

Other posters are suggesting version control, which I agree with, but don't be afraid to keep a revision history in the Project itself by adding a note to the project summary task. You can make it just a few sentences or as complex as a separate Word document.

Here are the instructions for MSProject 2010: enter image description here


As @jcmeloni, I used Project>Compare Projects, at least in the 2010 version. That showed the old and the new schedule by default. Linkages were more difficult to see changes in, but since they often changed the timing, that helped find them. This plus git gave me what I needed.

  • 1
    In Project 2013, "Compare Projects" is under the "Report" menu. – Gili Jan 31 '13 at 17:18

Ms Project files, as you mentioned, are binary and therefore can not be merged.

There is value in version control of these files, however, the checkouts must be exclusive to prevent merges.

Consider using Sharepoint for version control of Ms Office files instead of the version control you use for source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.