What's the difference between checkin and checkout?

Question

When teaching SCM classes to students that are new to Software Configuration Management, it happens that a question comes up like "What's the difference between checkin and checkout?".

And a variation of it is that such students get confused about these SCM concepts (they understand them as the other way around).

So what kind of metaphor can you use to explain this crucial SCM concept to such audience?

Solution 1

To explain something to anybody, try to compare it to something they are (hopefully) familiar with already.

So that's why I just answer such question like so:

Think of it as arriving at a place to stay (a hotel, a resort, etc):

• the very first thing you do (when you arrive) is to checkin.
• the very last thing you do (when you leave) is to checkout.

A similar SCM concept applies when you want to apply changes to software components ... except that it applies the other way around:

• the very first thing you do (when you start) is to checkout (or think of it like borrowing it).
• the very last thing you do (when you finish) is to checkin (or think of it like giving it back).

Note: this applies to centralized systems (such as the ones used in mainframe environments ...). In systems such as git the "checkout" concept has a completely different meaning (which IMO is also why in those systems there is hardly any confusion about both concepts).

Solution 2

It's important to note that the terms "checkin" and "checkout" have different meanings depending on the type of SCM system.

Centralized systems like TFVC, Subversion, and Clearcase use "exclusive" checkouts. This is like Pierre's book borrowing metaphor, where only one user can have a file checked out at one time.

Distributed systems like git have a "checkout" command, but it means something completely different. git checkout is used to switch between branches when working with a local repository.

Solution 3

For centralized systems, think of it like a technical library. (might be a stretch of the imagination how this hypothetical library functions...)

If you are an author of a document, you might checkout the library copy, make changes, return it check it back in to the library for the world to see.

This can become an issue if the library has digital copies, and I checkout a document, someone else also checks out a document, we both make changes, there will be a conflict (merge conflict) that might be difficult to resolve. When then the initial "fix" for this is exclusive checkout functionality...

---

Of course for large projects the chances of a critical merge conflict issue is reduced (people will be working on different parts of the system) so checkout/checkin is not needed nearly as much. And since distributed systems by design somewhat require good merge functionality, along with many other benefits, that concept doesn't really exist in git and other DVCS

Solution 4

With the SCM repository as the main subject then'

• checkout is getting changes out from the local or remote repository (into your local working directory).
• checkin is putting changes back into the the local or remote repository (from your local working directory).

Solution 5

• Checkout is an exclusive lock on modifying a branch of object in a repository.
• Checkin is a release of exclusive lock.

There are two kinds of source control systems depending on what is the smallest unit of branching.

1) Per repository branching (CVS, SVN, GIT, Perforce, ... etc)

In products where you branch the entire repository, checkout will usually either create or enable modifications to local branch (copy) of the entire repository. In those products checkin is often unused and becomes a part of commit operation, which is at once checkout of remote branch, applying of local patch and checkin of remote branch in single operation. You do not checkin your local branch as it is permanently checked out. (Note: In GIT you don't commit to remote branch, you push your local commit to it. Strictly syntactic difference.)

2) Per object branching (ClearCase, AccuRev, Oracle ADE)

In products where you branch individual objects, like directories, files, etc. The concept of checkout and checkin applies per object per branch. You will lock the object to modify it with checkout and release it with checkin. In those products you often work on a private branch where locks do not hold anyone from working and at the time of merge of your local branch into a shared branch, the objects are also checkedout on shard branch (main, master, feature branch, etc) conflicts of merge are resolved and object is checkedin on the shared branch. This allows multiple people to "commit" at the same time to shared branch as long as they do not modify the same objects.

View more solutions

Comments

[Admin]

checkout = lock ; checkin = unlock ; You take exclusive lock to edit the object in question on the branch on which you perform the operation.

[rpetrich]

Good point Dave about the distributed systems! Actually that's also why myself at first (when I first learned about GIT) was terribly confused. To not invalidate your answer (by adapting my question), I refined my own answer to clarify it a bit.

[rpetrich]

That's another way to look at it. Though in my experience I don't think it's a good idea to also add things like "conflicts" and "merging" (if they don't even feel comfortable yet with checkout and checkin).

[Toby Speight]

Perhaps the code is more like a library book than a hotel room?

[Thymine]

Fair, I added it because its the main reason that checkout/checkin exists that I could think of. And feel like grasping a concept is extra difficult if you don't know what that concept is actually useful for.

[Dave Swersky]

I should clarify: git checkout is used to check out objects from the repository. That can be a branch, or a single file.

[Jiri Klouda]

This is a rather naive, layman answer. I've worked for a decade on internals of source control systems so I've added a bit more in-depth answer to your question.

[rpetrich]

Hey Jiri, merci for your answer. For those 2 kinds you mentioned I would agree. But in the SCM tools in the mainframe world (were my experience originates from) one doesn't take "locking" into consideration ... Can you think of a way to add a 3rd kind to your answer?

[rpetrich]

Merci for this answer also. That's indeed a way to explain it, though I still wonder if you can think of some sort of "metaphor" (as in my question). E.g. to explain it to somebody you'd be teaching, who doesn't even have a clue what a local or remote repository really is.

[hlovdal]

True, if they have no clue about what a repository is then trying to teach checkin and checkout will be meaningless. Now, for a metaphor for source control in general you can compare it to financial accounting/bookkeeping. It is fundamentally keeping track of changes to the value of assets. You record either single individual changes or groups of changes (e.g. "Travel from A to B" rather than taxi ticket + bus ticker + train ticket + ...) although not too large groups (e.g. "All expenses on Monday"). Similarly a repository keeps track of source code changes, individual or not too large groups.

[Jiri Klouda]

Can you give me example of a product that does not fit in those two categories? I can either tell you which of the 2 it fits or add a third, if there really is one. Checkout and checkin are operations on a branch giving and releasing the right to modify it. So partitioning on what a product branches (whole repository or individual objects) is natural for this question. I don't know if there is anything in between, what would it be? Branching of subtrees as in Perforce and Subgit is essentially the first category. Lock is just a different name for an 'exclusive right to'.

[Jiri Klouda]

BTW The library metaphor as mentioned before is really a good one. When you checkout a book, you get an exclusive right to it. You take it home and do with it as you please. Read it or even scribble notes in the margins and nobody else can modify the book, while you have it checked out. Like remove some of its pages or highlight some lines. When you check in the book, people can read it at the library, where the watchful eye of librarian does not allow any modifications (vandalism) or check it out and take it home. It does serialize the changes to that book.

[Jiri Klouda]

To continue the analogy, in a different branch of the library, the same book might be there with different modifications or entirely unaltered or not at all. Someone else can check it out there at the same time (ie checkout is per branch). Now original author works on 2nd edition, a master branch so to speak. He could read notes from multiple branches, merge them together, checkout the master branch and checkin a 2nd edition. Each branch of library will refresh their copy by buying a 2nd edition. They can discard the 1st or copy still useful notes from margins to the new edition.