Introductory Programming In Java
| Lab 1 |
Lab 2 |
Lab 3 |
Lab 4 |
Lab 5 |
Lab 6 |
Lab 7 |
Lab 6
Learning Version Control with Mercurial
Objectives
To learn how to use a Source Code Management system Mercurial to document, preserve and organise all important versions of your code during the development cycle.
Introduction to SCM
Mercurial is a modern distributed version control system. "Distributed" means that every developer who is involved into a project maintains their own (local) repository, performs several revision changes and stores them in that repository until the project become "good enough" (mature, bug free) to be ready for sharing with others by uploading it to a central repository. In our case, when you work alone, your upload will serve as submission.
I am not providing detailed instructions here on how to use Mercurial.
Instead, you need to study one of the tutorials which are available on the Web.
There are many tutorials on how to use Mercurial. One of the most often used
is Joel Spolsky's Hg Init: a Mercurial tutorial,
of which you should read part one Ground up
Mercurial to learn the basics of managing your project using a local
repository and (just a little) of part two
Setting up for a Team (to learn how to
upload your local repository to a central server using hg push command).
When you use Mercurial, all acts of data transfer happen between the files which are part of your project in the working directory, your local repository and the central repository. As I said, the central repository will come into play only once, at the very end. When we talk about this data exchange, the following concepts are used:
- REPOSITORY is where Mercurial stores the revisions
- WORKING DIR is where you do your changes (work)
- CHANGESET is a set of changes committed at once
- REV is a number that identifies a revision
- PATCH is data to update from one revision (R1) to next (R2)
- PARENT is immediate ancestor to a revision (or WD)
- HEAD is a latest revision
In your working directory (like ass2, homework6 etc),
the first step would be to create a local repository. Let us assume that you
have started tour Assignment Two work by just downloading
ass2.zip file, uncompressing it into ass2 directory
and changing into it. To create a local repository, execute the command
hg init:
> pwd /students/u9207147/comp6700/assignments/ass2 > ls -la -rw-rw-rw- 1 u9207147 student 374 29 Apr 01:49 . -rw-rw-rw- 1 u9207147 student 476 29 Apr 19:08 .. -rw-rw-rw- 1 u9207147 student 422 28 Apr 18:59 Makefile -rw-rw-rw- 1 u9207147 student 1343 26 Apr 16:57 README -rw-rw-rw- 1 u9207147 student 119 28 Apr 19:00 args drwxrwxrwx 2 u9207147 student 68 28 Apr 20:43 bin -rw-rw-rw- 1 u9207147 student 43 1 May 2012 doc_args drwxrwxrwx 2 u9207147 student 68 28 Apr 20:43 docs -rw-rw-rw- 1 u9207147 student 118 26 Apr 16:19 files drwxrwxrwx 4 u9207147 student 136 29 Apr 01:49 src > hg init > ls -la -rw-rw-rw- 1 u9207147 student 374 29 Apr 01:49 . -rw-rw-rw- 1 u9207147 student 476 29 Apr 19:08 .. drwxr-xr-x 5 u9207147 student 170 30 Apr 12:30 .hg -rw-rw-rw- 1 u9207147 student 422 28 Apr 18:59 Makefile -rw-rw-rw- 1 u9207147 student 1343 26 Apr 16:57 README -rw-rw-rw- 1 u9207147 student 119 28 Apr 19:00 args drwxrwxrwx 2 u9207147 student 68 28 Apr 20:43 bin -rw-rw-rw- 1 u9207147 student 43 1 May 2012 doc_args drwxrwxrwx 2 u9207147 student 68 28 Apr 20:43 docs -rw-rw-rw- 1 u9207147 student 118 26 Apr 16:19 files drwxrwxrwx 4 u9207147 student 136 29 Apr 01:49 src
It is .hg directory created by the hg init
command which is your local repository for the ass2 project. At the beginning,
the repository is empty. You need to add those files which represent the artefacts
of you work, most importantly, your source code files.
> hg add src adding src/dotsandboxes/DotsAndBoxes.java adding src/dotsandboxes/Grid.java adding src/dotsandboxes/Vertex.java adding src/dotsandboxes/View.java > hg st A src/dotsandboxes/DotsAndBoxes.java A src/dotsandboxes/Grid.java A src/dotsandboxes/Vertex.java A src/dotsandboxes/View.java ? Makefile ? README ? args ? doc_args ? files
You should omit including all other files under the version control;
even if they change during your work, ignore these changes. Files which are NOT part
of the SCM are marked by "?" when you examine the status of your project with
hg st command.
Once you've made some changes to your code which can be considered as a new revision,
you should commit them to this repository using hg commit (or hg ci
for short; most of the hg commands have short aliases).
You will need to provide a log information, usually one sentence. You can do it inline
(most convenient), or by typing it and saving in a temporary file which Mercurial
will open for you (a default editor will be used, vi or nano
on Linux. You may be unfamiliar with how to save and quit it. You can learn how to control
which default editor is used by reading Mercurial documentation hg help config,
but my advice is to always use the commit command with -m option for
including the log message inline):
> hg commit -u u9207147 -m "Initial code for starting assignment 2" > hg log changeset: 0:c245aff37e1a tag: tip user: u9207147 date: Tue Apr 30 13:08:59 2013 +1000 summary: Initial code for starting assignment 2
You may choose to use an IDE (advisable!) for assignment work. All modern IDEs — Eclipse, Netbeans and Intellij IDEA — come with good support for Mercurial. You need to create the repository for source code files (and other important files if you like) from within the IDE.
Submission
While you are making revisions by committing changes into you local repository, you are forced to include a log entry for each of them. These logs can be read by others later to understand what every revision was about.
How to submit your work via Mercurial
| Lab 1 |
Lab 2 |
Lab 3 |
Lab 4 |
Lab 5 |
Lab 6 |
Lab 7 |
