 |
Hello, and welcome to the fifth episode of the Software Carpentry lecture on version control. In this episode, we will explain how to work with a version control system from the command line. |
 |
In the previous episodes, we showed you how to use the SmartSVN GUI to interact with your repository. |
 |
We will now show you how to accomplish these same tasks using commands from the shell, instead. |
 |
Running commands from the shell is faster than using SmartSVN, |
 |
And it is simple and not cluttered, unlike many GUIs. |
 |
In the prior episodes, Dracula’s first task was to check out a working copy of the repository. |
 |
To do this from the command line, we use the “svn checkout” command… |
 |
…or just “svn co” for short. |
 |
The checkout command takes two arguments. |
 |
The first argument is the location of the repository. |
 |
The second argument is the location for the working copy on your computer. |
 |
When the command is executed, the files in the repository are copied to Dracula’s computer. |
 |
He can then navigate to the working copy… |
 |
…and use the normal shell commands to view the files. |
 |
Once inside the working directory, the history of the project can be viewed using the “svn log” command… |
 |
…which gives a list of changes, and their details. |
 |
We see the comments… |
 |
…revision numbers… |
 |
…and the names of the editors, among other things. |
 |
Suppose Dracula now goes to the Jupiter folder, |
 |
and creates a new file called “moons.txt”. |
 |
(For details about file creation, please see the Software Carpentry lecture on the shell.) |
 |
After saving the file, Dracula wants to add it to the repository. |
 |
First, he uses the “svn add” command… |
 |
…with the location of the file as an argument. |
 |
This tells subversion to start keeping track of changes to the file. |
 |
Next, Dracula needs to commit the changes to the repository. |
 |
This is accomplished using the “svn commit” command. |
 |
To give a comment for the revision, the -m flag is used… |
 |
…followed by the comment, in quotation marks. |
 |
When Dracula executes the command, moons.txt is committed to the master copy of the repository. We are now on revision 7. |
 |
Wolfman, and any other users, will now need to update their working copies, since they are no longer at the latest revision. |
 |
Wolfman navigates to his working copy of the repository… |
 |
…and uses the “svn update” command. |
 |
Wolfman now has an up-to-date working copy. |
 |
Now that Wolfman has updated to the latest revision, he takes a look at moons.txt… |
 |
…and notices a spelling error. |
 |
He corrects the error… |
 |
…and also adds additional information about Amalthea. |
 |
Wolfman then commits his changes. |
 |
Later on, Dracula navigates to his working copy, and wants to see the changes that Wolfman has made to the repository. |
 |
To view such changes, we use “svn diff”, which displays differences between revisions |
 |
Specifically, to compare the master copy to the working copy, Dracula uses svn diff, with the -r flag. The -r flag indicates which revision we want to compare with the working copy. |
 |
To compare with the most recent revision, we pass the parameter “HEAD” |
 |
Execution of the command shows that the working version of moons.txt is different from the master version, and tells us which lines are different. |
 |
A minus sign at the beginning of a line indicates that the line is present in the master copy, but is missing in our local copy. |
 |
A plus sign indicates that the line is in the local copy, but not in the master copy. |
 |
Now that Dracula has reviewed the changes, he updates to the latest revision. |
 |
Both Wolfman and Dracula are up-to-date with the master copy, at revision 8. |
 |
Next, we will show you how to deal with conflicts from the command line. |
 |
Suppose Dracula and Wolfman are editing different lines of their local copies, but at the same time. |
 |
Dracula commits, and the repository is now at revision 9. |
 |
When Wolfman tries to commit, he gets an error: Commit failed. File or directory “moons.txt” is out of date. Try updating. |
 |
This error occurs because Wolfman is at revision 8, but the master copy is at revision 9. |
 |
To resolve this, Wolfman updates to revision 9. Since Dracula did not edit the same lines, the changes are merged without complaint. |
 |
Wolfman can now commit his changes. |
 |
Now, both Wolfman and Dracula add measurement units to the file. |
 |
Wolfman commits his changes, bringing us to revision 11. |
 |
When Dracula tries to commit, he gets an error, since he is not at the latest revision |
 |
He tries to update |
 |
But there is a conflict discovered in moons.txt, since he edited the same line as Wolfman. |
 |
To view the conflict, Dracula selects “diff full” by typing “df” |
 |
We get the following output |
 |
Between the less the row of less than signs, and the row of equals signs, we see what is in Dracula’s local copy, |
 |
Between the equals signs and greater than signs, we see what is in the master copy. |
 |
Now that we’ve identified the conflict, Dracula selects 'e' to edit the file. |
 |
This opens up a text editor. |
 |
In SmartSVN, we had a graphical tool for resolving conflicts. |
 |
We do not have this option in the shell. |
 |
Instead, Dracula must fix the conflict manually, through regular text editing. He corrects the conflict and saves the file… |
 |
…and is once again presented with a list of options. |
 |
This time Dracula selects 'r' for “resolved” |
 |
…and the update completes. |
 |
Dracula is now able to commit his changes. |
 |
Next, we will take about reversing changes. |
 |
Suppose Wolfman is up-to-date, at revision 12 |
 |
He makes some changes to moons.txt |
 |
But later realizes he wants to undo these changes. |
 |
Since he hasn’t committed his changes, he simply needs to revert his local copy |
 |
To throw away local changes, the “svn revert” command is used… |
 |
…with the name of the file as an argument |
 |
This will undo all the changes made to moons.txt |
 |
Suppose now that Dracula is up-to-date at revision 12. |
 |
He makes changes to moons.txt… |
 |
…and commits, creating revision 13. |
 |
He later decides that he wants to reverse these changes. |
 |
Revisions cannot be erased from the repository, |
 |
So instead, Dracula needs to copy revision 12 forward, merging with revision 13, to create a new revision. |
 |
Dracula uses the “svn merge” command |
 |
The -r flag specifies the range of revisions we are merging |
 |
To undo the changes that were made from revision 12 to revision 13, we write “HEAD” colon 12, since we are going backward in time from the most recent revision, to revision 12. |
 |
And then specify the file we are merging. |
 |
Dracula’s local copy of moons.txt is now back to what it looked like in revision 12. |
 |
He uses “svn diff” to verify that the changes have, indeed, been removed |
 |
He then commits, creating revision 14. The changes to moons.txt have been reversed. |
 |
To summarize, here is a list of the subversion commands that were covered in this episode. |
 |
|
Nice job. I normally use Subversion with TortoiseSVN — the server is FreeBSD, and the clients are always Windows. But I went through your slides in the terminal of an Ubuntu virtual machine and it was a very pleasant experience. Thank you for posting this and for having the slides with notes in addition to the video.
I would like to work on several different computers. All have internet access, but none are “networked”. Where would you put the repository and how would you access it from any computer you happen to be on? I was thinking about putting the repository on a portable hard drive and just carrying it around with me (will this work???) Any suggesstions are welcome.
@Nick
Hi Nick! I’ve answered your question in the “FAQ” section on the main Version Control page, located here.
The one tricky thing I found out was that when you try to do a reverse merge on the command line you have to put the numbers in decreasing order. For example, to reverse merge your current copy of a file back to revision 2, you should type “svn merge -r HEAD:2″.