A changeset is how source control systems keep track of changes. Everything else is built up around these changesets. But what are they?
Quite simply, it’s a difference. More specifically, a set of differences. What changes have you made since the last time you committed your code? These differences are saved as text and tracked by the source control tool.
Creating changesets is referred to as a commit
Imagine if you made a change to a document and someone else asks you, “What did you do to it?” So, you reply, “I added a line that says…”
That’s similar to a changeset (for a single file – more on this later). The person you’re talking to takes what they already knew about the document and adds the new information, the change of the new line, and now can picture the new updated document.
This can repeat for many changes. “I added another line that says …” And now the person you’re talking to takes the original document, plus the first change, and also plus this new change, and the final version of the document is known.
If you kept track of these changes, you’d be doing the basics of what a source code repository does. Consider the following timeline:
- Original Document
- Add paragraph ABC…
- Add line … to paragraph ABC
- Change introduction from A to B
You can then answer the same question for each point in time and get a different result: “What is the state of the document at change number X?” Each time, you start at #1 and add up the changes until you get to the desired point in time.
For a Single File?
Earlier in this post, I said that the document scenario was essentially a changeset for a single file. But a changeset can be a set of changes all at the same time. Consider the same document editing scenario, but for multiple documents. “I added a line to doc A, and I deleted a line to doc B”. Both of those changes can be saved at the same time in a set, a changeset.
This is the first of a planned series on using distributed source control. More to come in the future.