Design Document Guidelines #
Please use the following format for your Gitlet design document. We suggest that your design document be written in Markdown, a language that allows you to nicely format and style a text file. Organize your design document in a way that will make it easy for you or a course-staff member to read.
Design Overview #
Summarize the design of your system. Explain the major design choices you made, written in a manner such that an average 61BL student could take it, re-implement your project, and achieve a grade similar to yours by following your design. As a part of your design document, answer the following questions about your design in number-list format:
- How is your
.gitletdirectory structured? What files / classes are you using to represent your repository state, and what information is contained in these files / classes?
- What is the process of adding a file then committing? How does your
.gitletdirectory change after adding; then after committing?
- How does your design support operations that rely on branches? You should
explicitly account for
checkout [branch name], and
reset. Note: even though branches are not part of the checkpoint, we strongly encourage thinking about them earlier – you have a default branch, so your branch representation does actually affect your checkpoint implementation!
Serialization and Persistence #
Provide three (3) distinct sequences of commands. You must make sure to provide:
- What are the specific commands?
- What happens in the file system between each command? (i.e. are files created? Updated? Deleted?)
- To execute each command, what persisted information is necessary? Where do you get it from?
- How does your program perform the logic of the command? Describe your algorithm in detail, and the updates you make to your data structures and objects.
- After the command finishes, what persisted information needs to be updated so that future commands work appropriately?
Try to cover a variety of sequences of commands here. Feel free to abbreviate repetitive steps, though you should lay it out explicitly at least once.
To illustrate all this, we’ve created a sample design document for the Capers lab. The format is slightly different because Capers is not Gitlet.