IntroductionWelcome| 00:04 | Hello, I'm Michael Lehman, and welcome to
Fundamentals of Software Version Control.
| | 00:09 | In this course we'll look at how Software
Version Control tracks and maintains the history
| | 00:13 | of your creative output as you work.
| | 00:16 | I'll start by giving you an overview of the
principles of Version Control and talking
| | 00:20 | about key concepts and terminology used
in tracking changes using software tools.
| | 00:26 | Then we'll walk through how these concepts
are implemented in five of the most popular
| | 00:29 | version control systems: Subversion, Perforce,
Team Foundation Server, Git, and Mercurial.
| | 00:42 | We will be covering how these five products
can help you work faster, be more confident,
| | 00:47 | and sleep better, knowing that every stage
of your work is automatically preserved.
| | 00:52 | Now let's get started with
Fundamentals of Software Version Control.
| | 00:57 |
| | Collapse this transcript |
| What you should know before taking this course| 00:00 | In order to make the most of this course,
you should already know four key things:
| | 00:05 | how to install applications, how to run
applications on the command line, how to run applications
| | 00:11 | using the Windows Desktop, and how to edit
text files. With those four key skills, you'll
| | 00:17 | be able to start using Software Version
Control to automatically track your creative output.
| | 00:22 |
| | Collapse this transcript |
| Using the exercise files| 00:00 | As a member of the lynda.com online training
library, or if you are watching this tutorial
| | 00:05 | on a DVD-ROM, you have access to the
exercise files used throughout this title.
| | 00:10 | The Exercise Files folder contains four
folders, each of which contains an archived version
| | 00:15 | of the ending state of the Version Control
Repository for chapters 1, 4, 7, and 8 which
| | 00:22 | correspond to the initial Git demo, the Subversion
chapter, the Git chapter, and the Mercurial chapter.
| | 00:30 | Within each folder is one or more ZIP files
and a readme.txt file explaining how to unzip
| | 00:35 | the contents and connect them up
with the corresponding software.
| | 00:38 | There is also a file called Links.rtf
which contains the URLs for downloading all the
| | 00:45 | software used in this course and
other helpful reference websites.
| | 00:49 | Let's get started learning
about Software Version Control.
| | 00:54 |
| | Collapse this transcript |
|
|
1. Overview of Software Version ControlOverview of software version control| 00:01 | Hello, I am Michael Lehman, welcome to
Fundamentals of Software Version Control.
| | 00:06 | Version Control is the process of keeping
track of your creative output as it evolves
| | 00:10 | over the course of a project or product.
It tracks what is changed,
| | 00:16 | it tracks who changes it, and
it tracks why it was changed.
| | 00:24 | Keeping track of that evolution is vital.
| | 00:26 | Maybe you are a developer, an artist, a
writer, a composer, or a designer, you need it.
| | 00:32 | Perhaps you write source code, build scripts,
create images and icons or style sheets, you need it.
| | 00:38 | Do you write novels or screenplays?
| | 00:41 | Maybe you build spreadsheets or
record music. You need it too.
| | 00:45 | A team can use it, or you can use it for your
own private projects because remembering what
| | 00:51 | you've done and how it was done
is a key part of creative success.
| | 00:57 | Every good journey begins
with a story. This is mine.
| | 01:00 | A couple of months before I recorded this
course, the main drive in my laptop died.
| | 01:05 | It was one of those new high-speed solid-state
drives, which crashes by losing everything
| | 01:11 | with no hope of recovery.
| | 01:12 | For me, the biggest loss was
the files for this course.
| | 01:16 | While I did have a manually-created backup,
that ZIP only contained the latest versions.
| | 01:22 | What really saved me was the contents
of my cloud-based version control system.
| | 01:26 | Not only did it have the latest and greatest,
it contained all of the previous versions,
| | 01:31 | the seven drafts of the script, the 14 versions with
the PowerPoint slides, and the evolving table of contents.
| | 01:38 | But not only did it have the content, most
importantly, it contained the memory of what
| | 01:42 | I learned in the process of building the course.
| | 01:45 | After rebuilding my system disk, I synchronized
my local directories with the data from the
| | 01:49 | cloud, then I was back in business.
| | 01:51 | Now, I told you that story so I can say
this: everybody needs Version Control.
| | 01:57 | So what's your story?
| | 01:58 | Have you ever accidentally deleted the
wrong file or had your hard drive crash?
| | 02:03 | Have you ever made copies of an important
directory as you worked only to wonder later,
| | 02:06 | what's the difference between the working, the
better, and the final, final with bug fix directory?
| | 02:13 | Perhaps, more importantly, did you forget to
make a copy of an important file before you
| | 02:16 | started making changes and then
need to get back to the original?
| | 02:19 | Have you ever had to fix a bug in the bits
you shipped 2 months ago and didn't have
| | 02:23 | an easy way to get back to that exact state?
| | 02:25 | More than likely, you answered yes
to nearly all of these questions.
| | 02:29 | If so, Version Control tools such as Subversion,
Perforce, TFS, Git, and Mercurial will help
| | 02:37 | you be more organized, safeguard your source code,
and even get a better night's sleep. Sound good?
| | 02:43 | So let's explore Version Control and see how
easy it is to use and just exactly why it's
| | 02:48 | priceless when it saves the day.
Let's get started.
| | 02:53 |
| | Collapse this transcript |
| Understanding version control concepts| 00:00 | So what do you get from
Version Control software?
| | 00:03 | All Version Control systems provide four
important features: peace of mind, every time you make
| | 00:09 | an update and store it in source code control,
your files are backed up; history, not only
| | 00:15 | are the contents of your files backed up,
the actual changes you made and your comments
| | 00:19 | about why you made them are also captured
so that when you come back 3 months from
| | 00:23 | now, you can easily see what you changed,
and you can remember exactly why you did it.
| | 00:28 | This is because each change is accompanied by
a short message which after a bit of practice,
| | 00:33 | you will be the master of composing in a terse, pithy,
brief, succinct, compact, and to the point style;
| | 00:41 | friction-free undo, this means you can
easily move back to a previous version.
| | 00:45 | In some Version Control systems, this is
done on a file-by-file basis, and in some the
| | 00:50 | whole directory tree can be restored; and
fearless experimentation, in addition to creating
| | 00:55 | an automatic backup of your source code,
you can also create a sandbox in which you can
| | 00:59 | try out new features or make structural changes
without worrying that you're breaking what already works.
| | 01:05 | Version Control is even more important when
working in a team providing three additional
| | 01:09 | features: synchronization, when you store
your changes in source control, your team
| | 01:15 | members can easily update their copy of the
source code from your changes; accountability,
| | 01:20 | each time you store your changes, the Version
Control system marks those changes with your
| | 01:24 | user ID--this is crucial when working in a
team environment as each time you grab changes
| | 01:29 | made by someone else, you will be
able to see who made the changes and why;
| | 01:34 | and finally, conflict detection, when someone
on your team makes a change that the Version
| | 01:38 | Control system can't automatically merge with
yours, the system will notify you and help
| | 01:43 | you use differencing
tools to resolve the changes.
| | 01:47 | Without a tool like this, you might easily
overwrite someone else's changes and lose a critical update.
| | 01:52 | If you're not already using Version Control
software, you're probably already doing some
| | 01:56 | sort of change control by hand.
| | 01:58 | You might be using Save As to make backups of
individual files, duplicating and/or compressing
| | 02:04 | directories to take snapshots and hopefully
copying those backups to an external drive
| | 02:08 | or a cloud-based system.
| | 02:10 | The most time-consuming part of doing
Version Control by hand is trying to figure out the
| | 02:14 | difference between sets of changes.
| | 02:16 | So you end up with directories like MoneyMaker-Working,
MoneyMaker-ShipIt, and MoneyMaker-FinalFinalWithBugFixes
| | 02:24 | and then trying to figure out what's
the difference between those three.
| | 02:28 | After you make the move to Version Control
software, nearly everything is automatic.
| | 02:32 | As you work, each new version is
kept in a simple database-like system.
| | 02:36 | Tracking changes from one version to another
becomes the job of the Version Control system
| | 02:40 | which can not only show you the changes,
but it can help you remember why you made the
| | 02:45 | change, because as I said before ,you're
forced to add a comment each time you check in a
| | 02:49 | change and make an update.
| | 02:51 | You can also easily roll back to a specific
version of either a single file or a whole set of files.
| | 02:56 | And significant milestones can be marked by
a process called tagging, or labeling.
| | 03:01 | That means you can get back to that exact state
of the entire product, which can be especially
| | 03:05 | useful when you have to fix a bug in
release 2.3.11 you made last December.
| | 03:11 | So if you're ready to let Version Control
software help you keep track of what you're
| | 03:16 | doing and why you did it, let's get started.
| | 03:20 | Before we roll up our sleeves and actually
dig in, there are six key terms we need to
| | 03:24 | define and these work across all different
kinds of Version Control systems, but they
| | 03:28 | are key to understanding the basic
process, so the first one is repository.
| | 03:34 | A Version Control system is an application
or a set of applications that manage creating
| | 03:37 | a repository, which is the name of the specialized
database where your files and history are stored.
| | 03:43 | In some systems, this is in an actual database,
and in some systems this is done by creating
| | 03:48 | a set of small change files which are identified
by some identifier and managed by the software.
| | 03:55 | The next is working set.
| | 03:57 | Your files and folders can be organized
into projects within the repository in a manner
| | 04:01 | similar to how you manage files by
keeping them in folders on your hard drive.
| | 04:05 | The files on your hard drive, from the point
of view of the Version Control software, are
| | 04:09 | considered your working set.
| | 04:11 | You change the files in the working set and then
update the repository to reflect those updates,
| | 04:17 | automatically creating a backup and denoting
the purpose of the changes in a process--
| | 04:21 | that's called add when you are adding new files or
committing or checking in for existing files.
| | 04:27 | Once you have added or updated files in the
repository, you can easily revert your working
| | 04:32 | set with any version of
the data in the repository.
| | 04:35 | If you're working by yourself, you can grab
an older version. If you are working in a
| | 04:39 | team, you can grab files that have
been updated by your team members.
| | 04:42 | That process is either called updating or
checking out, and finally as we talked about
| | 04:48 | before, you can mark the state of an entire
project tree or an entire repository with
| | 04:53 | an identifier called either a tag, or a
label depending on the vendor, when significant
| | 04:58 | events occur such as shipping a
release or delivering it to a client.
| | 05:02 | Next step, we are going to take a look
at a Version Control system in action.
| | 05:06 | First, we'll look at it conceptually, and
then we'll open a command line and actually run
| | 05:11 | a Version Control system
so you can see it in action.
| | 05:16 |
| | Collapse this transcript |
| Demo one: Getting started| 00:00 | Let's take a look at Version Control in action.
| | 00:02 | First, we'll look at it conceptually,
and then we'll actually do it.
| | 00:07 | So in this diagram, the repository where
your files are kept is represented by the large
| | 00:12 | right-facing arrow and contains the
different versions of our files over time.
| | 00:17 | So at 9 a.m., you create a
repository for your new project.
| | 00:21 | This creates the empty database to
which you can add files to be tracked.
| | 00:26 | Oftentimes this is done
by a command called Init.
| | 00:28 | At 10 o'clock you create myprog.c
and add just the main function.
| | 00:34 | Then you add it to your repository by checking
it in. With each add or check in, Version Control
| | 00:41 | systems ask you to compose a short message
indicating why you are performing the check in.
| | 00:45 | In this case, we'll say add myprog.c.
| | 00:49 | Later on at 4 o'clock, you edit myprog.c again
and add Func1 and save it back to your hard disk.
| | 00:56 | This updates your working set, making it
different from now what's stored in your repository,
| | 01:00 | so you check in again.
| | 01:02 | Now your repository has two versions
of your file and two commit messages.
| | 01:07 | Later that night, you're so excited about
the app you're building and how easy it is to
| | 01:11 | use Version Control to keep
track of what you're doing,
| | 01:13 | you add Func2 and check it
in again at 1 a.m. What a day.
| | 01:18 | Now let's look at this in
a live version using Git.
| | 01:22 | Okay, let's roll up our sleeves and
actually use a live Version Control system.
| | 01:27 | We're going to use Git since it's one of
the most popular systems currently being used
| | 01:31 | in the software development world, and it's easy to use
from the command line on Windows, Macintosh, and Linux.
| | 01:37 | We've installed Git by using one of the
download links, and the Links.rtf file you'll find in
| | 01:42 | the Exercise File directory.
| | 01:44 | We're not going to go through the installation
process here, we'll cover that in the chapter on Git.
| | 01:49 | To begin, we'll open the Command window as
I've done here, and the first thing we are
| | 01:53 | going to do is validate the Git installation.
We'll do that by typing git --version, and hitting Enter.
| | 02:00 | What you should see is something like this,
git version 1.7...whatever there is there
| | 02:06 | in the rest of that line. That's going to vary,
depending upon which build of Git you've actually
| | 02:10 | chosen to download and install.
| | 02:13 | Now that we've got Git installed
correctly, we're going to proceed.
| | 02:17 | So the first thing we need to do is make a
directory called FSVC1, for Fundamentals of
| | 02:21 | Software Version Control, and
then we'll change to that directory.
| | 02:30 | Once we're inside that directory,
type git init to create the repository.
| | 02:35 | Git doesn't store its changes in a single
database file representing the repository,
| | 02:40 | rather Git stores the data about your files
and directories and all their history in a
| | 02:44 | hidden directory named .git.
| | 02:47 | To see that directory on Windows, we type dir /a,
so there we can see the .git directory.
| | 02:53 | We can verify that the repository is
properly initialized by running git status.
| | 02:58 | And as you can see, the message displays
containing string to say On branch master,
| | 03:04 | Initial commit, and nothing to commit.
| | 03:07 | This means that your working set is in the
same state as your repository. So now Step 2.
| | 03:13 | We're going to create myprog.c
and add it to the repository.
| | 03:17 | On Windows we'll use Notepad, on OS X
or Linux use our favorite Text Editor.
| | 03:22 | So here we go, Notepad myprog.c.
| | 03:25 | So first time we're going to create it, so
we'll say yes, we want to create a new file,
| | 03:30 | and now we're going to add Main.
And then we're going to save it.
| | 03:38 | Now our working set is different
than the state of our repository.
| | 03:42 | So every time you add new files, you have
to tell Git to start tracking those files.
| | 03:47 | You can do that in two stages or in one stage.
In two stages, we're going to do it this way.
| | 03:51 | The first time you type git add and then star, and it's
going to add all the files it doesn't know about.
| | 03:58 | And then if we run git status again, you
can see it now knows, oh, I have a new file.
| | 04:07 | In order to get the file into the repository,
we're going to commit it, so we're going to
| | 04:13 | type git commit -a -m, and
then a message, add myprog.c.
| | 04:22 | The first thing we're going to see is it didn't
work because it said I don't know who you are.
| | 04:27 | Every Version Control system needs to know
who you are, so it can attribute all the changes
| | 04:31 | that you make to you for your own purposes.
That's pretty much you all the time, but when
| | 04:37 | you're working in a team
situation, that can be very crucial.
| | 04:40 | So we're going to run these two
commands that you see here on the screen.
| | 04:42 | We're going to say git config --global user.email,
and we're going to say you@example.com, and
| | 04:55 | then we're going to say git config --global user.name,
and we're going to say "lynda.com student".
| | 05:05 | Now of course, you want to put in your own
email address here and your own name or user ID,
| | 05:10 | if you're working in a team.
| | 05:12 | Whatever it is, you've all collectively
agreed on whether you're going to use your email
| | 05:16 | aliases or your actual name, but for the
purposes of the course, we're going to use these strings
| | 05:21 | for your own purposes.
| | 05:22 | Make sure you put in your
own email and your own name.
| | 05:24 | All right, now that we've done this, we
can go back and try our commit again.
| | 05:30 | And in this case, the commit worked.
| | 05:33 | You can see that it said one
file changed and one insertion.
| | 05:37 | So the string, add myprog.c is a sample of
the kind of the message I mentioned before
| | 05:42 | that you enter for each commit
to indicate what you've changed.
| | 05:46 | This message should be short and meaningful
to either allow a future you or your fellow
| | 05:50 | developers to understand
why you made this commit.
| | 05:54 | Note, on Windows the string
should always be in double quotes.
| | 05:58 | On OS X and Linux, it can be in single quotes,
and we can verify that we've committed everything
| | 06:03 | to the repository again by running git status,
and you can see nothing to commit. That means
| | 06:09 | we've added everything that we needed to.
| | 06:12 | Now, even though we've only taken one short
step, we can now ask the Version Control system
| | 06:18 | to tell us the history, and in Git you say git log -p,
and you can see this is a full detailed history.
| | 06:27 | It says that Author: lynda.com student at
you@exampleemail.com on the date that you
| | 06:35 | do it, added this file, and then it actually
runs a diff and shows you the difference between
| | 06:40 | the previous version and the current version.
| | 06:42 | Now in this particular case, the previous
version was a new file, so what we see are the lines
| | 06:47 | here in green which says
we've added the main function.
| | 06:52 | Now let's move on to make it change and
see how versions are actually tracked.
| | 06:56 | Let's reopen myprog.c and add Func1.
| | 07:07 | And we'll save it back, and then once again as we did before,
we'll commit it, so git commit -a -m "Add Func1 ()".
| | 07:20 | And you can see we made one file
change, and we made two insertions.
| | 07:24 | So now let's once again see how that change is
tracked by Git by once again running git log -p.
| | 07:32 | So now you can see that we've got at the top
of the screen here the definition that when
| | 07:36 | we added Func1, the full diff, you can see the
blank line and the line with Func1 in green there.
| | 07:43 | And then you can see down below that there
is the information about the previous commit
| | 07:47 | we made where it says add myprog, and you
can see at the bottom of the screen now there
| | 07:50 | is a Colon with a
flashing cursor next to it.
| | 07:53 | When the list of changes is longer than a
page, the paging mode is automatically invoked,
| | 07:58 | so you need to hit the Spacebar until the
Terminal window displays the word End and
| | 08:02 | then type the letter Q to get
back to your command prompt.
| | 08:06 | So let's do the final step.
| | 08:07 | I'll open up myprog.c one
more time and add Func2.
| | 08:21 | Once again, save our file
and then do our commit again.
| | 08:30 | In case you're wondering what that -a is on
the command line, the -m is for the message,
| | 08:34 | the -a is basically making it possible
for you to do git commits in a single step.
| | 08:40 | By default, you can do git commits in two
steps, like we did, and we added the first
| | 08:43 | file where you added and
then subsequently commit it.
| | 08:46 | Most of the time when I use Git, I just do
it all at once so that I can say make all
| | 08:52 | of my changes, and then I don't have to
worry about whether I've added files, or I have
| | 08:55 | changed files by putting
that -a in the Git commit line.
| | 08:59 | It automatically adds all the new files so
that it handles it all as a single operation.
| | 09:04 | So once again, we'll run git log -p, and we
can see now that we've added Func2 and then
| | 09:11 | we added Func1 and then we added
myprog.c and finally we got to our end.
| | 09:17 | Now you can see when you use
git log -p, that is very verbose.
| | 09:21 | There is a way of telling Git to get a
shorter version of the history of the repository,
| | 09:26 | so we do it like this.
| | 09:27 | We say git log, now we give
it some different arguments.
| | 09:31 | In this case we say --oneline, because we
want each revision to be on a single line, and
| | 09:36 | we want to see all of them. So we say --all.
| | 09:41 | And here we can see in reverse chronological
order our three commits with their commit messages.
| | 09:48 | The number you see in yellow there at the
left is the ID, sometimes called the change
| | 09:52 | set ID or the check in ID.
| | 09:56 | Each different Version Control system does
something slightly different, but there's
| | 09:59 | always an ID that uniquely
identifies the set of changes that you made.
| | 10:04 | So now let's ask Git to show us the difference
between our initial check in and the most recent check in.
| | 10:10 | The way we do that is we actually use
these IDs and use the git diff command.
| | 10:15 | So we're going to say git diff, and we're
going to put in the oldest one here, 6a3e577,
| | 10:24 | now these numbers will be different for you.
| | 10:25 | You'll have to look on your screen and see which
GUIDs get created for this, and then we'll say 7555e83.
| | 10:35 | And so you can see that it says in white that
in the original one it only had the main function
| | 10:42 | and in the most recent one, the
Function1 and Function2 were added.
| | 10:47 | When we get into we are actually doing delete.
You'll see that delete show up as red lines.
| | 10:51 | All right, well that's about 80% of
everything you need to know to use Version Control.
| | 10:57 | Let's look at the remaining 20% again
conceptually and then we'll see it in action.
| | 11:02 |
| | Collapse this transcript |
| Demo two: Handling the "oops"| 00:00 | Picking up from where we left off before we'd
created a repository and made a few check-ins,
| | 00:04 | and you check things in at 1
o'clock in the morning, and you are happy.
| | 00:08 | So the next day you open up myprog.c, and you
realize that Func1, it's not exactly what you wanted.
| | 00:17 | So you delete that, and as you are now
well into the habit, you check in again.
| | 00:21 | Then you get inspired and add
Func3, and of course, check that in.
| | 00:27 | After a bit of a reflection, you think
maybe I could combine some of the functionality
| | 00:30 | of Func3 into Func2.
| | 00:33 | So you open up myprog.c,
and again, start editing.
| | 00:36 | Midway through that process, you say to yourself--
and this is the important part after saving
| | 00:40 | myprog.c back to the disk, wiping out the
previous version--oops, I guess that isn't going to work.
| | 00:47 | Now in the days before your use of Version
Control, you start sweating and wondering where you
| | 00:51 | made a backup copy?
| | 00:52 | Was it in that best-best final with bug fixes
directory or in the best-best ship it directory?
| | 00:58 | And you try to figure out how
you could recover your work.
| | 01:01 | But now that you've got Version Control on
your side, you simply revert myprog.c back
| | 01:05 | to the latest version of your repository,
and you're ready to move forward again in
| | 01:09 | moments, hero mode on. Now let's
go see that on the command line.
| | 01:15 | So once again we find ourselves here at the
command line. As before, we're inside our fsvc1
| | 01:21 | directory where our source
code is there is our myprog.c.
| | 01:25 | So let's open up myprog.c and delete Func1.
| | 01:35 | Now we can run the git diff command and see
what's the difference between what's in our
| | 01:39 | working set and what's in the repository.
| | 01:44 | Now in this case, we only have one file, so
it's very easy in more sophisticated situations.
| | 01:49 | You probably want to be able to specify
either the file that you're working on or a subset
| | 01:53 | of the directory; otherwise, you may end up
with pages and pages and pages of this output.
| | 01:58 | So we can see that the Func1 code has a minus
sign at the beginning and is in red, indicating
| | 02:03 | that the code was deleted.
| | 02:04 | So let's check in this change, and then
as you're beginning to trust Version Control,
| | 02:16 | there is no need to look at the log at this
point, so let's just go ahead and add Func3.
| | 02:19 | So once again we'll come back and edit
this, save it, and I will check that in.
| | 02:38 | All right, and then we can run git log --oneline
--all, see all of our changes, so we can see
| | 02:45 | we've--if we read from the bottom--we added it.
| | 02:47 | We added Func1, we added Func2,
we deleted Func1, we added Func3.
| | 02:52 | Now, we see our full list of commits.
| | 02:55 | So now that we have all the numbers, we can
run the git diff command between our check in
| | 03:00 | number 3 Add Func2 and
our most recent Add Func3.
| | 03:05 | So we say git diff and the number there,
7555e83 and 4b8ed72, and you can see that it shows
| | 03:18 | between those two different diversions
we removed Func1, and we added Func3.
| | 03:22 | So now let's once again edit myprog.c and
come down here and delete Func3, and then we're
| | 03:32 | actually going to save it, and you can see
myprog.c no longer has Func3 in it, and we realize
| | 03:40 | we didn't really want to do that.
| | 03:42 | So in order to figure out exactly which
version we want to restore--and in this case, we know
| | 03:47 | it's the most recent one--in Git we can say
git diff HEAD, and it shows us that the difference
| | 03:54 | between the repository and the working set
is that the working set has Func3 removed.
| | 04:00 | So what we want to do is restore our working set
to the latest state, to what was in the repository.
| | 04:05 | So now we say git checkout myprog.c, and
then if we type it out again, you can see
| | 04:15 | Func3 is back in its full glory.
| | 04:18 | And then we can see what the Version Control
system thinks again, by typing git diff HEAD,
| | 04:25 | and you can see that there is no difference
between the working set now and the repository.
| | 04:30 | And one other way--as we just ran git diff
and saw that we didn't have any differences
| | 04:36 | between our working set and our repository--
| | 04:38 | another way to verify the repository is up to
date with your working set is to say git status,
| | 04:44 | and again, it will show nothing to commit.
| | 04:48 | Now at this point, we're going to take this entire
directory, including all the git hidden directory.
| | 04:55 | Remember, we have this .git hidden directory,
and if we just go take a quick look in there,
| | 04:58 | there is a whole bunch of additional directories
and files that keep track of all the versioning
| | 05:04 | information, this is the repository information.
| | 05:06 | For this particular thing, we're going to zip this
entire thing and put it into the Exercise Files directory.
| | 05:12 | If you then take that and unzip it in any
directory that you want, and you come back
| | 05:17 | to this top level, you can then say git log
--oneline -all, and see the same thing that
| | 05:26 | we just did here step by step in the course,
and you can experiment with this particular
| | 05:31 | repository to your heart's content, adding
additional things, doing additional commits, practicing
| | 05:37 | doing reverts in an environment where you
know you have a repository that has some known
| | 05:42 | working states that's compact enough to
really understand, as opposed to somebody handing
| | 05:47 | you a repository of 25 or 150
files with 200 commits already made.
| | 05:53 | So next up, we'll look at a short history of
Version Control and review the specific terminology
| | 05:58 | that applies to all Version Control
systems we'll be using in this course.
| | 06:03 |
| | Collapse this transcript |
|
|
2. Background of Software Version ControlThe history of version control| 00:00 | Before we begin using the modern Version Control
Systems, a little bit of history is worth looking at.
| | 00:06 | The first Version Control System was created
in 1972 at Bell Labs where they developed UNIX.
| | 00:12 | The first one was called SCCS.
| | 00:14 | It was available only for UNIX and
only worked with Source Code files.
| | 00:19 | Ten years later the Revision Control System,
or RCS, was developed, and it was the first
| | 00:24 | cross-platform version control system,
but once again, it was only for text files.
| | 00:29 | Both SCCS and RCS only worked on the
development system and were not for sharing code, as they
| | 00:34 | only worked for a single user.
| | 00:37 | The next wave of Version Control Software--
what we call Centralized Version Control--
| | 00:42 | was developed starting in 1986.
| | 00:45 | The Concurrent Versions System, or CVS, was
the first one that had a central repository
| | 00:50 | and was usable by multiple users.
| | 00:53 | It was still file-focused and kept track
of changes in individual files, as opposed to
| | 00:57 | keeping track of changes
in entire directory trees.
| | 01:01 | Later on in the 1980s, along came Perforce,
and it was widely used during the .com era.
| | 01:07 | It's still the biggest
repository used inside Google.
| | 01:09 | In 2000, a new product called Subversion was
created and supported non-text files, tracking
| | 01:16 | directory structure changes, such as file
renames and moves, and its transaction unit was the
| | 01:21 | directory as opposed to an individual file.
| | 01:24 | So you could check in an entire
directory tree and check it out.
| | 01:28 | In 2004, Microsoft created the Team Foundation
Server to replace its aging Visual SourceSafe
| | 01:34 | Version Control System, which was
primarily a client server system.
| | 01:38 | TFS comes with an MSDN subscription,
which means it's fairly expensive.
| | 01:42 | But it also has a TFS Express edition
which is usable for up to I believe 5 users.
| | 01:49 | TFS has tight Visual Studio integration.
| | 01:52 | That means you can check in and check
out right from inside Visual Studio.
| | 01:56 | It supports not only source code control,
but also has bug and work item tracking and
| | 02:01 | features for doing automated testing.
| | 02:03 | The next generation of source code control
software is called Distributed Source Code Control.
| | 02:08 | Distributed Source Code Control is
different in that there's not a central server that
| | 02:12 | everybody shares. Everybody shares their
own individual repository and then can share
| | 02:18 | their changes with a central server or
share their changes with individual users.
| | 02:24 | Distributed Source Code Control came about because of
a change in licensing from a company called BitKeeper.
| | 02:30 | Previously, they had a product which was
used by Linus Torvalds and the kernel group on
| | 02:35 | Linux that was called the
Community Edition, and it was free.
| | 02:39 | But in 2005, BitKeeper decided to make its
entire product line commercial only, meaning
| | 02:43 | you had to pay a fee for using it, and Linus
decided that he wanted to make sure that everything
| | 02:47 | around Linux was free, and so
he created something called Git.
| | 02:52 | It's broadly used in conjunction with
something called GitHub which is an online cloud-based
| | 02:57 | service which offers free hosting for open-source
projects and also commercial hosting for private use.
| | 03:04 | A competing product Mercurial was also
created in 2005 in response to the same BitKeeper
| | 03:10 | change and is also widely
used in open source projects.
| | 03:14 | That's a short history of
Version Control from 1972 to 2012.
| | 03:20 | These days, pretty much everybody uses one
of five systems, Perforce, Subversion, or TFS
| | 03:26 | if they want a centralized system, Git or
Mercurial if they want a distributed system.
| | 03:31 | And now that we have looked at the history,
let's move on to looking at a little bit more
| | 03:35 | details about the terminology that we need
to understand, and a walk-through about how
| | 03:41 | centralized and distributed systems work.
| | 03:46 |
| | Collapse this transcript |
| Terminology| 00:00 | Before we proceed into talking more about
centralized and distributed version control,
| | 00:04 | it's time to add a few
more terms to our lexicon.
| | 00:08 | Here is the terms we've already discussed:
repository, the database where your changes
| | 00:12 | are tracked; working set, your local files
with potential changes not yet in the repository;
| | 00:18 | add and check in, ways of getting data in
to the repository; check-out and update, ways
| | 00:24 | of getting data from the repository into
your working set; and revert or rollback, ways
| | 00:29 | of updating your working set to match
specific versions of the repository.
| | 00:35 | Distributed Repository Systems have the
ability to take the contents of an entire repository,
| | 00:39 | or the contents of a particular changeset, and send
it to other users collaborating on the same project.
| | 00:45 | When sending changes from one repository to
another, you can do it via two methods, one
| | 00:50 | is to use a method which uses HTTP or SSH
to communicate the information to a remote
| | 00:57 | server, the other is a way of extracting data
from a repository to be able to send by email.
| | 01:03 | So, when sending changes from one repository
to another repository on a server, the terms
| | 01:08 | are called push and pull.
| | 01:10 | Push sends the changes from your repository
to the server's repository, and pull gets
| | 01:15 | the changes from the server and
adds them to your local repository.
| | 01:20 | As I said, this is almost often done
via a server listing on HTTP or via SSH.
| | 01:25 | If you wish to send your changes privately
using email, you can do the same thing, but
| | 01:29 | the terms are called import and export.
| | 01:32 | You export from a repository which extracts
the changes from your repository and puts
| | 01:37 | them in a file that you can send as an
attachment, and conversely, import allows you to take
| | 01:41 | that file that somebody else sends you as an
attachment and update your local repository.
| | 01:47 | One of the most important features in a
Version Control Software is the ability to name the
| | 01:51 | specific state of a repository.
| | 01:53 | This, as I said before, is
called tagging or labeling.
| | 01:56 | This allows you to say all the files that
I have in this particular repository ,or all
| | 02:00 | the files that I have in this project in a
repository or in a well-known state, and I
| | 02:05 | want to be able to get back to the state later.
| | 02:07 | For example, when you ship version 1 before
you begin to work on version 2, and 2 months
| | 02:13 | later your customers says I need to make a
change in version 1 right now and can't wait
| | 02:17 | for version 2, you want to be able to get
back to that exact state of version 1 so that
| | 02:21 | you can make that update so that you can
extract all the files that represent the state of
| | 02:26 | your product or website or composition as
a version 1, make some changes, and saves
| | 02:32 | them back in a way that's separate from
what the new stuff you're working on version 2.
| | 02:37 | Sometimes when you're working on a project,
you want to do some experiments, and we'll
| | 02:40 | say what if I re-factor this particular function,
or what if we redid the size of the website,
| | 02:45 | or what if we decided to take out this
chorus and add another bridge in the song?
| | 02:50 | Version Control Software allows you to
make a copy of your entire repository and work
| | 02:54 | on this in a private sandbox.
This is called branching or forking.
| | 02:59 | Once you've done all your experimental work,
you may decide that this is exactly what you
| | 03:02 | want, and wish to add your changes back
into the main portion of your source code.
| | 03:07 | This is called merging.
| | 03:08 | The thing that you branched from is oftentimes
called the main branch or sometimes called the trunk.
| | 03:14 | So what you want to do when you merge is
integrate from your private branch back into the trunk
| | 03:19 | or into the main branch.
| | 03:22 | Sometimes you do this because your product
is composed of a lot of pieces, and you want
| | 03:25 | to be able to work on the
individual pieces separately.
| | 03:28 | For example, you might have an app that has
an image processing component and an audio
| | 03:32 | component, and two different
developers work on each of these pieces.
| | 03:36 | So, in this case, you would create two
branches, one for the image processing developer to
| | 03:41 | use, and one for the audio
recording developer to use.
| | 03:44 | Then when the image processing developer
completes her work, she merges her future updates back
| | 03:48 | into the main trunk.
| | 03:50 | This is a special kind of
merging called reverse integration.
| | 03:54 | If the audio developer has also done a
reverse integration and merged updates back into the
| | 03:57 | main branch, the image processing developer
may want to get those changes before proceeding
| | 04:03 | on and making additional changes.
| | 04:05 | So, she can grab the updates from the main
branch in a process that's called forward
| | 04:09 | integration, which is kind
of like creating a new branch.
| | 04:12 | It simply takes the changes from the main
trunk and puts them into her private branch.
| | 04:17 | And similarly, the audio developer can do the
same thing with the image processing changes.
| | 04:23 | We'll see this both conceptually
and in action later in the course.
| | 04:28 |
| | Collapse this transcript |
| Exploring centralized vs. distributed systems| 00:00 | As mentioned in the section about history
of Version Control, there are two different
| | 00:04 | kinds of version control:
Centralized, and Distributed.
| | 00:08 | The workflow between these two different kinds
are somewhat different, so I thought it would
| | 00:11 | be worthwhile to go over the way in which
these things are actually used from the point
| | 00:16 | of view of a user using version control.
| | 00:19 | So first, we'll talk about
centralized version control.
| | 00:22 | Typically, in centralized version control, a
system admin creates the repository because
| | 00:26 | the repository is always remote.
| | 00:29 | Then you have your local working set, and you
add or check in files to the remote repository,
| | 00:35 | and you check out or revert
files to update your working set.
| | 00:39 | Similarly, another user using a centralized
version control system will connect up to
| | 00:43 | the remote repository and
have a different working set.
| | 00:47 | They will check out your files and updates
that you've made and add their own, and this
| | 00:52 | goes back and forth in this check in/check-out
update loop as you work with Version Control.
| | 00:58 | But in this case, in Centralized Version Control,
everything is kept in the remote repository.
| | 01:03 | Now, some benefits of that are that the
system administrator can then keep track of
| | 01:07 | updates, can manage backups, can do system
rollbacks for all the developers at once.
| | 01:15 | But it tends to be somewhat fragile, and it
also tends to be problematic when you can't
| | 01:20 | get access to the centralized server, if
the server is down, if you're on an airplane,
| | 01:25 | it becomes kind of cumbersome.
| | 01:26 | So it depends on the magnitude of your project
and the magnitude of your team, whether centralized
| | 01:32 | version control is right for you, and we'll
look back at that at the end of the course,
| | 01:36 | looking at all the different Version Control
Systems, and exploring how you can determine
| | 01:40 | what's the right one to use
for your particular project.
| | 01:44 | Distributed Version Control
works a little bit differently.
| | 01:47 | Typically, you initialize the repository
because the repository is on your local box.
| | 01:53 | Similar to the Centralized Version Control,
you still have a working set, and you add
| | 01:56 | things and you update them.
| | 01:58 | In addition, you can also have this optional
remote repository, which is a way of backing things up.
| | 02:04 | Now typically, people that use Git or
Mercurial use a system like this, and they will use
| | 02:09 | a hosted system like GitHub in order to be
able to back up their local repository into
| | 02:14 | the cloud, and that's done as we mentioned
just before in terminology by using push and pull.
| | 02:20 | Similarly, if that remote repository is not
in the cloud but on another developer system,
| | 02:26 | you would use import and export to send the
data back and forth between the repositories.
| | 02:32 | So that's a little bit of a look at the differences
between centralized and distributed version control.
| | 02:36 | Next, we are going to jump into all the
concepts in more detail about getting things in, getting
| | 02:42 | things out, how the process of history
tracking works, and all of the information that you
| | 02:47 | need to understand before we begin to look
at specific version control implementations.
| | 02:52 |
| | Collapse this transcript |
|
|
3. Version Control ConceptsGetting files in and out of a repository| 00:00 | The first thing you need to know to use
Version Control is how to create either the entire
| | 00:04 | repository or how to create a portion of the
repository for the project you're working on.
| | 00:09 | For a Centralized Version Control, most often
the repository itself is created for you by
| | 00:14 | your system administrator.
| | 00:16 | With Distributed Version Control, you'll create the
repository yourself at least on your local machine.
| | 00:22 | And then you may synchronize it with another
repository created on the server by an administrator.
| | 00:26 | So you create the repository by using a command that's
sometimes called initialize and sometimes called create.
| | 00:33 | And what this does is create an empty
space for you to put your files and directories
| | 00:37 | in, as we did in our sample before where
we simply created myprog.c and checked it in.
| | 00:45 | If your files already exist, meaning you're
adding an existing project to Version Control,
| | 00:50 | you can use the Add feature of your Version
Control Software to bulk add all the files
| | 00:55 | and directories into your
working set and then check them in.
| | 00:59 | In Distributed Version Control, there's
usually a concept between your file system and the
| | 01:05 | repository that's called the staging area.
| | 01:08 | So, when you actually do an add, the files
go from your working set into the staging
| | 01:13 | area and then from the staging area into
the repository, because 99% of the time, the
| | 01:20 | concept of using the staging area as two steps is more
than you actually need, as we did in the previous demos.
| | 01:28 | I did git commit -a -m and the -a meant
add any files that are in the working set
| | 01:36 | that aren't already in the
repository automatically.
| | 01:39 | So I could do that commit as a single step.
| | 01:41 | Now of course, once you've got your files
in, you want to get them back out in order to
| | 01:46 | be able to work on them.
| | 01:48 | And depending on the type of Version Control
System you're using, whether it's Centralized
| | 01:52 | or Distributed, you may be required to tell
the Version Control System that you're going
| | 01:56 | to start making changes to the files.
| | 01:59 | Most centralized systems
have the concept of check out.
| | 02:02 | This means that you are telling the Version
Control System that you are going to work on this file.
| | 02:05 | So it will actually lock the file so other
people cannot make changes until you check it back in.
| | 02:10 | So, version Perforce and TFS allow you to
specify which kinds of files, and which files
| | 02:17 | require a lock on checkout,
and which files don't.
| | 02:21 | For example, you would typically require a
lock on files that are non-textual, like images,
| | 02:27 | or Zip files, or audio recordings, because
the Version Control System can't easily detect
| | 02:34 | the subtlety of a change in one portion of an
image that you make and a change in another
| | 02:38 | portion of an image that someone else
makes and actually merge them together.
| | 02:43 | So, if the files are not locked on checkout,
then you might end up with conflicts when
| | 02:48 | you check them back in.
| | 02:49 | So, the reason that the centralized systems
put the lock on there is to make sure that
| | 02:54 | it's easy to make sure that reduces the
number of conflicts and the number of problems you
| | 02:59 | have checking in and merging.
| | 03:00 | So for example, if Joe makes changes to a
file, and then Arlene also makes changes to
| | 03:04 | the same file, Joe can check his file, and
then later when Arlene tries to check in, the
| | 03:09 | server says that the changes conflict,
and she ends up doing a manual differencing
| | 03:14 | in order to resolve these things.
| | 03:17 | TFS in particular has a feature called
shelving which allows you to check out files and lock
| | 03:23 | them, and then if you're not finished
working on them before somebody else needs to make
| | 03:27 | a change, you are going to actually take all
the files you have checked out and put them
| | 03:31 | in to what's called a shelf set, and
essentially puts them up on the shelf so that the files
| | 03:36 | can be unlocked and other people can work
on it and then you can take your shelf set
| | 03:40 | off the shelf, put it back into your working
set, and do some more changes and then check
| | 03:44 | in, because your changes don't necessarily
conflict with what somebody else needed to do.
| | 03:50 | But since the system actually locks the files,
you may want to make sure that the person
| | 03:54 | who needs to get in there can actually
make those changes when they need to.
| | 03:58 | Distributed Version Control Systems like Git
and Mercurial specifically have made the concept
| | 04:04 | of branching super lightweight.
| | 04:06 | When you say git branch, it actually simply
creates one extra file, and doesn't make literally
| | 04:12 | a second copy of the entire
directory in your working set.
| | 04:17 | And when using Git and Mercurial in a team,
the workflow is usually instead of locking
| | 04:23 | the files, you actually branch the entire
repository, make your changes, and then merge
| | 04:27 | back in because it's such a lightweight process.
| | 04:30 | We'll dig into more about that when we talk
about branching and merging and when we demonstrate
| | 04:35 | branching and merging in Mercurial and Git.
| | 04:40 |
| | Collapse this transcript |
| Saving changes and tracking history| 00:01 | Once you've got your files in, and you can
get your files out, the typical workflow when using
| | 00:05 | any Version Control System
looks like this in your repository.
| | 00:09 | At Time 1, you can see that there's a file
in your repository that contains A, B, and C.
| | 00:14 | Let's say you check it out and
then you delete B and you add D.
| | 00:18 | Now when you save your files back into the repository,
use a command that's called commit, check in, or update.
| | 00:24 | When you command the Version Control System
to save your updated file, it will ask you
| | 00:28 | for a short description
of the changes you've made.
| | 00:31 | This is oftentimes called a commit message, and this is
a crucial part of the history of tracking information.
| | 00:37 | The system will store the differences
between the two different versions of the file, and
| | 00:41 | you supply the reason.
| | 00:42 | In some systems you can supply a single line,
and in some systems you can actually supply
| | 00:47 | not only a single line which is used in short
displays, you can also provide an entire document
| | 00:53 | that describes what it is. Reference bugs
that are fixed by this have hyperlinks to
| | 00:58 | websites that have
appropriate references and so forth.
| | 01:02 | Once you've added a file to Version
Control and made a change and checked it back in,
| | 01:06 | your Version Control System can now
show you the history of that file.
| | 01:09 | So, we can see here we have the file here
at T1 with our initial commit, then we have
| | 01:14 | two versions of file, and we add D, and now
three versions of the file when we deleted B,
| | 01:19 | and four versions of the file when we add E.
| | 01:22 | Each item in the history will show you not
only what is changed between one version and
| | 01:26 | the other, it will also show you who made the
changes, and what that person said about those changes.
| | 01:31 | In this case, initial commit,
adding D, deleting B, and so forth.
| | 01:35 | It's important when creating commit or check in
messages to be as descriptive as possible,
| | 01:40 | because you may come back later and your
memory may be a little fuzzy as to what you changed,
| | 01:44 | or when you're working on a team, someone
else may be reading your commit message
| | 01:48 | and want to learn to understand what you did.
| | 01:51 | Many systems allow you to create a one-line
short commit message, and in certain systems,
| | 01:55 | you can also create a longer descriptive
message in which you can be more detailed
| | 01:59 | in terms of what you've actually changed.
| | 02:01 | You can add hyperlinks, you can add references to
documents, you can add references to bug numbers.
| | 02:07 | When you're using the Command Line tools,
you can only add the short version, or if
| | 02:11 | you leave the short version text off, the
Command Line version of the tools will open
| | 02:15 | up in the editor to allow you to put in
both the short version, and the subsequent long
| | 02:20 | version on subsequent lines.
| | 02:21 | If you think back to our demo when I typed
in git commit -a - and then put that string
| | 02:27 | in quotes, if you leave the string off, it will
open up in editor, showing you the information
| | 02:32 | about what files have changed, and allowing you
to enter in both the short and the long version,
| | 02:37 | keeping track of the changes, automatically
backing up your files, recording why something
| | 02:43 | was changed, and who changed it
is the essence of Version Control.
| | 02:48 |
| | Collapse this transcript |
| Reverting to a prior version| 00:01 | Sometimes when you make changes to a file,
they turn out not to be what you want.
| | 00:05 | You may open a file and accidentally delete
too much and then save it back and realize,
| | 00:09 | oh, I can't do any undo because
I am already out of my editor.
| | 00:13 | You may change the color palette of an image and
then not remember what the original RGB values were.
| | 00:18 | You may do some refactoring and then
realize when you're done it's not the way you want
| | 00:22 | to do it, and you want to start over.
| | 00:24 | This is one of the places where Version
Control systems can really help you out.
| | 00:27 | So you've got your file in the repository
at time T1, you would check it out or
| | 00:32 | update it as necessary, and
you begin to make some changes.
| | 00:35 | You delete feature B and add feature D and
then you realize that's not the way you want it.
| | 00:41 | So with Version Control software, you can go
back and say please overwrite the file in my
| | 00:45 | working set with the most recently saved one,
or even overwrite the file or the entire working
| | 00:51 | set with the version from last Thursday.
| | 00:53 | This is sometimes called reverting,
and in some systems it's called rollback.
| | 00:56 | Now, the key thing is that you have to
identify the specific version you want to roll back to.
| | 01:02 | Each time you commit or check in, the Version
Control Software creates a changeset identifier.
| | 01:08 | You can see here in the stack of files we
have on the left that when we added feature C
| | 01:12 | that created changeset number 23.
| | 01:15 | So at anytime you can say, hey, I want to
roll back to that particular changeset, and
| | 01:20 | you tell it to revert to changeset 23, and
now the working set has, well, it's at time 2,
| | 01:26 | it has exactly what was in the file at
the time you saved it as changeset 23.
| | 01:32 | This is one of the big key
benefits of using Version Control.
| | 01:35 | You get the freedom to work quickly and the security of
knowing the Version Control Software always has your back.
| | 01:41 |
| | Collapse this transcript |
| Creating tags and labels| 00:01 | While changeset identifiers are great for
identifying individual changes, in some systems--
| | 00:06 | particularly centralized ones--a changeset
only reflects the files that were actually
| | 00:11 | changed during a particular check in or commit.
| | 00:14 | For example, here we have an initial commit and
then a second commit where we added feature D.
| | 00:19 | Sometimes you want to be able to identify the
entire state of the repository at a particular
| | 00:24 | point in time, such as a customer
release or a major milestone of the project.
| | 00:29 | Rather than writing down a cryptic
changeset identifier, Version Control systems allow
| | 00:33 | you to supply a human readable name
describing the current state of the whole repository
| | 00:37 | or project, in our case here, V1.0.
| | 00:41 | This is called tagging in some
systems and labeling in others.
| | 00:44 | Now we can continue on and delete feature B and
add feature E and then label it again version 1.1.
| | 00:51 | I highly recommend that you take advantage
of this on a regular basis, whether it's week
| | 00:56 | by week, feature by feature, or release by
release, because you'll find that the more
| | 01:00 | you tag and label, the more your
Version Control system could do for you.
| | 01:05 |
| | Collapse this transcript |
| Branching and merging| 00:00 | One of the most useful features of Software
Version Control is called branching, but it's
| | 00:05 | sometimes the most confusing.
| | 00:07 | Some of the centralized systems make it
somewhat complicated to merge two different branches
| | 00:11 | together, so some people feel that
branching is complex, but the branching part really
| | 00:16 | couldn't be any easier.
| | 00:19 | You start out with your main branch and your
existing files, and you create a new branch,
| | 00:25 | and now you have another set of
identical files that you can make changes to.
| | 00:29 | Because all branching means is that you're
taking the current state of the repository
| | 00:32 | and creating a new copy.
| | 00:35 | In the new branch, as opposed to the main
branch--which is also sometimes called the trunk--
| | 00:38 | you can make any changes you want and they
don't affect the product that is already working.
| | 00:45 | This is a perfect sandbox in which you
can experiment and you can refactor code.
| | 00:49 | You can delete old unnecessary
features and add brand-new ones.
| | 00:54 | You really have full freedom
to do anything you want to.
| | 00:57 | In our example, a repository contains
a file containing features A, B, and C.
| | 01:02 | Once you branch you can see the main trunk
still contains A, B, and C, and so does the branch.
| | 01:07 | Now, at T2 we may delete C and add feature D.
| | 01:13 | And this doesn't have anything to do with
what we can do in the main branch, where we
| | 01:16 | might, for example, add feature F.
| | 01:19 | And back in the branch we might
delete feature B now and add feature E.
| | 01:23 | And this is all without
changing our main production code.
| | 01:28 | In distributed systems such as Git and
Mercurial, branching is actually really, really easy
| | 01:33 | and cheap because it only really creates a
40-byte file, simply creating a new GUID,
| | 01:39 | indicating a new path of changes, that
doesn't actually make a separate copy of the files.
| | 01:45 | Hand in hand with branching is
the reverse process, called merging.
| | 01:49 | This allows you to take changes that you've
made in a branch and add them back into the
| | 01:53 | main trunk or into another branch.
So let's take a look.
| | 01:57 | We have our main branch, there is our main
file, we'll create a new branch, as we did
| | 02:02 | before, feature 1, and we'll take
the copy and we'll add feature D.
| | 02:08 | And now back in the main
branch, we'll add feature F.
| | 02:12 | And here in parallel, we're going to
add feature E in the feature 1 branch.
| | 02:17 | So as you do these changes, you might decide you
like both sets of changes and want to combine them.
| | 02:22 | In this case, we don't have any conflicting changes
because we didn't delete anything, we just added.
| | 02:28 | So now we ask our Version Control system to
merge the two branches together, and now we
| | 02:33 | end up with a new file 1, checked into the
main branch with all the features from both
| | 02:38 | the main branch and the feature branch.
| | 02:41 | When there are conflicts, such as two changes
in each branch that effectively did the same
| | 02:45 | thing, for example, if we deleted feature
B in both the main branch and the feature
| | 02:51 | 1 branch, the Version Control Software
sometimes can't tell exactly what you meant to do and
| | 02:56 | so therefore it declares a merge conflict
and requests that you resolve this manually.
| | 03:02 | What happens is it brings up a differencing
tool to allow you the human to look at the
| | 03:06 | lines that have changed in context and make
a decision of whether you want to take the
| | 03:11 | version from the main branch or the
version from your feature branch or both changes.
| | 03:17 | On Windows, I highly recommend a tool called
Beyond Compare to use as your differencing tool.
| | 03:22 | On the Mac and Linux, there are many, many
different tools that will allow you to do this effectively.
| | 03:28 | One of the great benefits of Version Control
Software beyond differencing is that not only
| | 03:32 | will it require you to see the various
changes that you've made, it will allow you to see
| | 03:36 | the commit messages to determine the intent
of the developer who made the changes so that
| | 03:41 | you can understand how to merge the
two branches together effectively.
| | 03:46 | Branching and Merging are the two most
powerful features in any Version Control system, and
| | 03:50 | when used with care and thought, they can
be the most powerful feature that you can
| | 03:55 | use, because they allow you to experiment
or work in parallel and then bring your work
| | 03:59 | back together again at the end to
create a completed product or project.
| | 04:03 | So use branches whenever you want to be sure
that the main branch or any other branch stays intact.
| | 04:11 |
| | Collapse this transcript |
| Exploring workflow integration and continuous builds| 00:01 | Some Version Control systems, such as
Microsoft's Team Foundation Server, have what's called
| | 00:06 | Integrated Workflow Item Tracking.
| | 00:08 | This means you can have your testers
associate a bug with a particular check in.
| | 00:14 | So a developer who does coding checks in the
source code, a tester does some testing and
| | 00:19 | finds a bug, so they log the bug. In
this case, it's called creating a work item.
| | 00:24 | That work item now represents a
particular issue that's going on in the software.
| | 00:28 | It goes back to the developer who fixes the
bug, and then when they commit their change
| | 00:33 | to the Source Code Control System, the work item is
also associated with that particular commit message
| | 00:39 | so that when the tester receives the
notification that, that work item has been updated, they
| | 00:43 | not only have the commit message that the
developer created, they also know exactly
| | 00:48 | which bug which they created is associated
with that, so they can verify that the bug
| | 00:52 | has in fact been fixed.
| | 00:54 | Here we can see an example. This is the Team
Foundation Server Explorer inside Visual Studio,
| | 01:00 | and here we have Work Items, and you can
actually query for the Work Items that are associated
| | 01:05 | with your particular user.
| | 01:08 | Here we have a tester creating a New Work
Item, and here the tester creates a new bug.
| | 01:13 | In this case, Microsoft calls this an Issue,
and they can fill in Priority and Status and
| | 01:19 | a Description, add File Attachments,
everything that a tester might want to be able to give
| | 01:23 | to a developer to help them fix the bug.
| | 01:26 | Another development technique that is often used in team
scenarios is something called continuous build systems.
| | 01:32 | This means that every time you make a
change to the Source Code, the product is rebuilt
| | 01:36 | to verify that your changes are compatible
with all the other changes being made to the
| | 01:40 | system before the changeset is
recorded permanently in the repository.
| | 01:45 | So the developer makes changes to the
Source Code and does the check in and the system
| | 01:49 | then runs a build to verify that the
changes that were checked in built cleanly.
| | 01:54 | You can even make sure that the build
system actually runs unit tests to make sure that
| | 01:58 | they test cleanly before actually
committing the changes to the repository.
| | 02:02 | I know that previous to this I said that
the words check in and commit are equivalent,
| | 02:07 | but in this particular scenario, the terms
actually get split apart a little bit in order
| | 02:12 | to be able to handle this
multiphase committing process.
| | 02:15 | So the developer does a check in and then
the system does a build verification, and then
| | 02:20 | once the build verification as passed, then the
changes are actually committed to the repository.
| | 02:25 | And here we can see in TFS a number of the
different kinds of build quality gates that
| | 02:30 | can be set up to determine when
the code is actually committed.
| | 02:34 | As you start to use Version Control, consider
how it can work with the other tools you are
| | 02:37 | already using, such as build servers and bug
tracking systems, and you can create a more
| | 02:42 | powerful tool out of the
combination of these tools.
| | 02:47 |
| | Collapse this transcript |
| Using graphical user interface (GUI) tools| 00:01 | Almost all Version Control systems have at least
four different ways of accessing the repository.
| | 00:05 | First, as we've already
seen is the command line.
| | 00:09 | Most Version Control systems also have Window
tools or GUI tools to access the repository.
| | 00:15 | Some Version Control systems also offer
integration into your favorite Integrated Development
| | 00:19 | Environment, or IDE, such
as Eclipse or Visual Studio.
| | 00:23 | And many third-party tools allow integration
into the file browser built into your operating
| | 00:27 | systems, such as the Mac Finder or the Windows
Explorer, and this is sometimes called shell integration.
| | 00:33 | In this movie we'll look at the GUI tools,
and in the next two movies we'll look at IDE
| | 00:38 | integration and shell integration.
| | 00:40 | Here we're going to look at five GUI tools
available for the five Version Control products
| | 00:45 | that we're going to be
covering in subsequent chapters.
| | 00:47 | There's not a GUI tool for Subversion for
Windows, but there is a very nice GUI tool
| | 00:53 | called Versions that's available on the Mac.
| | 00:56 | Perforce has a Visual Client that works on
both Windows and Mac, and they also have a
| | 01:00 | web client which works on Mac and Linux.
| | 01:03 | Microsoft's Team Foundation Server only works
on Windows, but they have both the Team Explorer,
| | 01:09 | which is a stand-alone GUI, and IDE integration, which we'll
see in the next movie, which works with Visual Studio.
| | 01:16 | If you use a hosted cloud provider such as
GitHub, GitHub has a very nice GUI tool that
| | 01:22 | allows you to work with teams, integrate issue tracking,
and do code review, which is available here at github.com.
| | 01:29 | For Mercurial, there's a nice visual tool
available only for the Macintosh, which is called MacHg.
| | 01:35 | It not only allows you to see your changesets
and see inside the changesets, it also allows
| | 01:40 | you to see a graph of the branching and
merging so that you can visually understand how all
| | 01:44 | the different changesets relate to one another.
| | 01:47 | The GUI tools all include functionality that
allow you to do bulk add, check in and check-out,
| | 01:51 | reverting, branching and merging.
| | 01:54 | They will also allow you to look at the
repository and open up a file in the native file browser,
| | 02:00 | such as you'll be able to right-click on the
file and say Show in Finder or Show in Windows
| | 02:05 | Explorer to actually open up the file system
to correspond to the file that's in the Version
| | 02:09 | Control system so that you can locate the
actual files that are in your working set.
| | 02:14 | As you can see, most visual tools provide
advanced functionality that provides visual
| | 02:19 | ways of performing the functionality that's
specific to the Version Control system that they support.
| | 02:24 | GUI tools can be really handy and
can allow you to work really fast.
| | 02:28 | If you're not comfortable with working on the
command line, GUI tools provide a great alternative.
| | 02:32 | If you are a command line junkie, you can
do everything you want to from the command
| | 02:36 | line and never have to touch a GUI tool.
| | 02:41 |
| | Collapse this transcript |
| Integrating a version control system with an integrated development environment (IDE)| 00:01 | Two of the most popular development
environments, Microsoft's Visual Studio and Apple's Xcode
| | 00:06 | have integration with Source Code
Control built right into the IDE.
| | 00:09 | In Xcode, Git is supported natively.
| | 00:12 | In Visual Studio, Microsoft provides
support for Team Foundation Server and many third
| | 00:17 | parties provide support for Git
Subversion, Perforce, and Mercurial.
| | 00:22 | In many of these integrated development
environments, the environment will automatically check files
| | 00:25 | out for you when you begin modifying them
and support check in, reverting, branching
| | 00:31 | right within the IDE.
So let's take a look at Visual Studio.
| | 00:35 | Here we have a solution inside Visual Studio,
a simple console application which has a
| | 00:39 | main program and two separate features.
| | 00:42 | I've gone ahead and created a project
inside the Team Foundation Server on CodePlex and
| | 00:46 | prepared to add this project to TFS.
| | 00:50 | You can see the green plus signs right
here and right here, next to each one of these
| | 00:54 | things, indicating that an add is pending.
| | 00:57 | But the code has not yet been checked into
TFS, so let's go through that process.
| | 01:01 | As you can see, it's not only here in the
Source Code Control Explorer, but also over
| | 01:06 | here in the Solution Explorer, the status of the files
within the Version Control system are clearly indicated.
| | 01:13 | So we'll come over here to the application,
and we'll select Check In Pending Changes.
| | 01:17 | First, it asks if you want to save your
changes to make sure that the working set on disk
| | 01:21 | is updated with the contents of the working
set inside the application, so we'll save that.
| | 01:26 | And now we have a Pending Changes tab over
here now in the Team Explorer which has a
| | 01:31 | place for our commit Comment.
| | 01:33 | So we'll say Initial
add of ConsoleApplication1.
| | 01:39 | In more sophisticated things, you can actually
associate related work items, decide exactly
| | 01:44 | which changes you want.
| | 01:45 | In this case, we're all set to go,
we're going to click Check In.
| | 01:49 | It asks us if we want to continue to check
in 9 items, we'll say yes, and you can see now
| | 01:53 | here it says Changeset
18686 successfully checked in.
| | 01:58 | And now if we go over here and look in the
Source Control Explorer, we'll see not only
| | 02:02 | the folders, but we can actually see
all of the files that are checked in.
| | 02:07 | Here's the Properties folder, the App.config,
and all of the files that we checked in.
| | 02:10 | And if we come back to the Solution Explorer,
we can now see this little lock icon, which
| | 02:15 | means that these files are actually checked in.
| | 02:18 | If we open up one of these in order to be
able to do some editing, and we start typing,
| | 02:22 | you can see over here in the Solution
Explorer that it has a little red check mark, which
| | 02:27 | means it's checked out to me.
| | 02:29 | So that's the power of using a Version
Control system integrated into the IDE is you don't
| | 02:34 | have to go separately to your Version Control
and think about the process of using Version
| | 02:38 | Control while you're developing.
| | 02:41 | While using a Version Control system in an
IDE can be very powerful, don't forget there
| | 02:45 | will be times when it fails, so always
keep the command line reference handy.
| | 02:50 |
| | Collapse this transcript |
| Examining shell integration| 00:01 | We've looked at command line interfaces for
Version Control, GUI interfaces for Version
| | 00:05 | Control, IDE integration for Version Control,
and finally the last way you can access Version
| | 00:09 | Control is through a
process called shell integration.
| | 00:13 | This means that instead of just looking at
the project file inside your IDE, you can
| | 00:17 | actually look at the file in directory tree
inside the Windows Explorer or the Macintosh
| | 00:21 | Finder, or their equivalent on Linux, and
actually look at the files in your working set where
| | 00:26 | they live and interact
with Version Control there.
| | 00:29 | That allows you to add files, check files
in, check files out, revert, all from right
| | 00:34 | inside whatever the shell is
that you're currently using.
| | 00:37 | It can show you which files are up to date,
which files are checked out, which files have
| | 00:41 | pending changes, sometimes
even which files have conflicts.
| | 00:45 | The way they do this is by providing context
menus so that you go to a file or a directory
| | 00:50 | and right-click, and you'll see a series of
context menus that allow you to check in and check out.
| | 00:55 | They also have visual status indicators,
such as green dots for files that are checked in
| | 01:00 | and red check marks for files
that are checked out and so forth.
| | 01:03 | So let's take a look at the shell
integrations available for Windows and for Macintosh for
| | 01:07 | the five Source Code Control
providers we're looking at in this course.
| | 01:11 | First, for Windows there is a
product called TortoiseSVN.
| | 01:15 | This is a Windows Explorer extension
for using Subversion with Windows.
| | 01:20 | Perforce provides a product called the Perforce
Plug-in for Windows Explorer that adds a Perforce
| | 01:25 | menu to the standard
Explorer context menu in Windows.
| | 01:30 | For Team Foundation Server, Microsoft
provides the Team Foundation Server Power Tools.
| | 01:35 | While this is not part of the released Visual
Studio product, it is something that is kept
| | 01:40 | up to date with every release of Visual Studio
and provides, not only Windows Explorer integration,
| | 01:45 | but provides a number of additional facilities.
| | 01:47 | If you're using TFS, I highly recommend
getting the Team Foundation Server Power Tools.
| | 01:52 | For Git, there is an open-source project
over here on code.google.com called TortoiseGit
| | 01:58 | that provides something
similar to TortoiseSVN but for Git.
| | 02:01 | As you can see here in the Context menu,
you can Pull and Fetch and Push and Show the
| | 02:07 | logs and Resolve, Revert. Everything that
you can do on the command line, you can do
| | 02:11 | from this Context menu.
| | 02:13 | And the final integration for Windows is
TortoiseHG, which is again, Tortoise for Mercurial, and
| | 02:20 | you can see here it allows you
to Add Files and Revert Files.
| | 02:23 | And here you can see an example of the
kinds of icons that are enhanced when using one
| | 02:27 | of these shell extensions.
| | 02:28 | Here you can see files that are checked in, files
that still need to be added, files that have a conflict.
| | 02:35 | Similarly, for the Macintosh there is a
product here called SCPlugin, which is Subversion.
| | 02:42 | They call it here a file-icon badging and
commands from Finder. Essentially, it creates
| | 02:46 | a context menu in the Finder
that has Subversion commands on it.
| | 02:51 | Similarly, DeltaWalker is an equivalent
functionality for Git that does Finder extensions.
| | 02:58 | And over here in Bitbucket, this Mercurial
Finder Integration project is relatively new,
| | 03:03 | but someone is in the process of trying to provide
the Mercurial functionality as a Finder integration.
| | 03:10 | So we've looked at the four different ways
that you can interact within your Version
| | 03:12 | Control software, there is the command line,
there is stand-alone GUI tools, there is IDE
| | 03:18 | integration, and finally there is shell
integration that allows you to add context menus to the
| | 03:23 | Macintosh Finder or the Windows Explorer.
| | 03:28 |
| | Collapse this transcript |
| Looking at forward and reverse integration| 00:01 | The last set of advanced features we're going to cover
are called forward integration and reverse integration.
| | 00:06 | These are a process that you
use with branching and merging.
| | 00:09 | Consider you might have a product, as we talked
about before, but it has two separate features
| | 00:14 | that can be worked on by two
different developers independently.
| | 00:17 | If these two different features interact,
as your developers each work in their private
| | 00:21 | branch, they may want to from time to time
check their changes into the main branch so
| | 00:25 | the other developer can get them, and they
may also want to get changes from the main
| | 00:29 | branch back into their
private branch to continue working.
| | 00:32 | So let's take a look and see how that works.
| | 00:34 | So we start out with our main branch, and
we create two separate branches, one for each
| | 00:38 | developer, feature 1 branch,
and feature 2 branch.
| | 00:42 | Initially, they both contain the same set
of information that's in the main branch,
| | 00:45 | and now they begin to diverge individually.
| | 00:48 | In the feature 1 branch, developer number
one adds feature D and then decides because
| | 00:54 | developer number 2 may need to be able to
use feature D, they check it back into the
| | 00:57 | main branch in a process
that's called reverse integration.
| | 01:01 | Now, the reason this is more than just a merge
is that the first developer is going to continue
| | 01:06 | to work in their feature 1 branch as
opposed to moving back to the main branch.
| | 01:10 | Now, developer number two continues to work
in their own private branch here in feature 2
| | 01:15 | branch and adds feature E.
| | 01:17 | When they're done, they check that in, again,
through another process called reverse integration.
| | 01:23 | In order for developer 1 to continue to keep
working in their private branch and yet still
| | 01:28 | take advantage of the code for feature E, they
go through a process called forward integration,
| | 01:32 | which allows them to take changes from the main
branch and put them back into their private branch.
| | 01:37 | Now, this is slightly different
than creating just a new branch.
| | 01:41 | Similarly, developer number 2 might do a
forward integration back into their private branch
| | 01:45 | in order to pick up feature D.
| | 01:47 | In the end, when you get to the final point
where the product is shipped, feature 2 branch,
| | 01:52 | feature 1 branch, and the main branch all
have exactly the same code, because they've
| | 01:56 | all been integrated together through a series
of reverse integrations and forward integrations.
| | 02:01 | What's interesting about this is when you look
at really, really large development projects,
| | 02:06 | this is the way they work.
| | 02:07 | For example, inside Microsoft, Windows is
done this way, Visual Studio is done this way.
| | 02:13 | In Visual Studio there are
teams of hundreds of developers.
| | 02:16 | One team works on Visual Basic, one team
works on Visual C#, one team works on the Editor,
| | 02:22 | another team works on the XAML visual designer,
and all of those teams work independently,
| | 02:27 | going through numerous forward and reverse
integrations over the course of creating a
| | 02:31 | new version of Visual Studio, only to end up
with all of the teams having their branches
| | 02:36 | be equal to the final shipping product.
| | 02:41 |
| | Collapse this transcript |
|
|
4. SubversionInstallation and setup| 00:00 | All right. Let's roll up our sleeves
and dig into Subversion.
| | 00:04 | Subversion, as we mentioned earlier is
a centralized Version Control system.
| | 00:09 | This means there's one repository shared by multiple
people if multiple people are working on a project.
| | 00:15 | You can also use Subversion in a local
installation, which is what we're going to do here, but
| | 00:21 | that repository is not something which you
can export like you can with Git and Mercurial.
| | 00:26 | It's really a single repository that's used
by you. And if you set up a server to be able
| | 00:32 | to access that, other
people could also access it.
| | 00:36 | There are both free and
commercial options for subversion.
| | 00:39 | As I said for free, you can download and
install a local version, you can also use it with
| | 00:44 | Microsoft's CodePlex website, which is free
for open-source projects, and there's a 45-day
| | 00:50 | free trial of a commercial
version at codespaces.com.
| | 00:55 | All these links as with all other links in
the course are also going to be in the Links.rtf
| | 01:00 | file inside the Exercise Files directory.
| | 01:03 | So first up, let's install the local
version of Subversion, which is abbreviated SVN on
| | 01:09 | the command line, and I'll be calling it SVN from
time to time throughout the rest of this chapter.
| | 01:15 | The Subversion install is a
straightforward MSI-based installation.
| | 01:18 | So let's fire it up.
| | 01:20 | Now, usually where I install subversion is
in the C:\svn directory, it makes it much
| | 01:26 | easier rather than putting it in Program Files,
because then you have a directory name with
| | 01:30 | spaces, and if you're running on a 64-bit
version of Windows, you end up with the space,
| | 01:36 | parenthesis, x86, so it's easy to just
to install it here in C:\svn. All right.
| | 01:43 | So we've got Subversion installed.
| | 01:46 | Let's open up a command box and make sure that we've
got all the paths and environment variables set correctly.
| | 01:52 | So we type svn --version, and you should see
something like this, and the most recent version
| | 02:00 | as we recorded this course was 1.7.6.
| | 02:03 | Now, it's possible if you have some
applications open, that a reboot may be required, but in
| | 02:08 | our case, everything was
closed down, so we can proceed on.
| | 02:13 | Once this installation is
complete, there's one additional step.
| | 02:16 | All of the environment variables are
set with one notable exception, SVN_EDITOR.
| | 02:22 | If we look at our environment variables, we
can see when we look in the esses, that particular
| | 02:26 | environment variable is not set.
| | 02:28 | This editor is invoked whenever a commit message is
required, and you don't supply one on the command line.
| | 02:34 | This is particularly useful when you
want to do multi-line commit messages.
| | 02:38 | To set this easily, you can say set SVN_EDITOR=
Notepad, or whatever other editor you prefer to use,
| | 02:47 | as long this is on your path, and if we type set again,
we can see now that that environment variable is set.
| | 02:55 | If you want to set this permanently, come
to the Start menu, right-click on Computer,
| | 02:59 | select Properties, select Advanced system
settings, select Environment Variables, and then click
| | 03:05 | New in here and add it into
your Environment Variables.
| | 03:09 | Note that after you've done this, it
doesn't actually set that environment variable for
| | 03:13 | any existing open command prompts, so you have
to close your command prompt and open it up again.
| | 03:18 | For this course, we're simply going to use it,
and we're setting it on the command line.
| | 03:24 | That's the installation of Subversion.
We've got our editor set.
| | 03:27 | Let's move on to start
creating a repository and a project.
| | 03:32 |
| | Collapse this transcript |
| Creating a repository and a project| 00:00 | Now that we've got Subversion installed, let's create
a repository and then a project inside that repository.
| | 00:07 | Creating a repository in Subversion
is easy, use the svnadmin command.
| | 00:11 | So we're going to say svnadmin create c:\svn\r1,
r1 is the name of the repository you want to create.
| | 00:21 | You don't have to create it inside the SVN
directory, but it's a convenient way to make
| | 00:25 | it easy to back up all the repositories
by simply backing up the SVN directory.
| | 00:30 | Next step, we need to create a project.
| | 00:33 | Project setup in Subversion can appear to be
somewhat complex, but once you have learned
| | 00:36 | how to do it, it's the same every time.
| | 00:39 | There is a set of conventions that are
commonly used so that if you move from one group to
| | 00:44 | another that's using some version, you'll
see the same kind of pattern being used because
| | 00:49 | it makes it easy to do branches and
tags and keep track of which is the trunk.
| | 00:53 | So, I always name my projects, as you know XXX-YYY,
where XXX is the name of the repository
| | 01:01 | and YYY is the name of the project.
| | 01:03 | So then I know just by being in the
project directory where everything is located.
| | 01:07 | So we'll create the project by saying svn
mkdir and then create the URI and then use
| | 01:14 | the URI for our repository r1/r1-p1 and then we'll
create a commit message for that, "Create project p1".
| | 01:25 | All right. Our project is now there.
| | 01:28 | Now as I mentioned, using SVN is the convention
regarding how the project directories are set up.
| | 01:34 | This involves creating three specific directories, one
called branches, one called tags, and one called trunk.
| | 01:40 | If you have an existing directory of source
code, what I would suggest you do is go there,
| | 01:45 | create these three directories, and then move
the original contents of your directory into
| | 01:49 | the trunk subdirectory before doing the import.
| | 01:52 | Since we don't have an existing directory,
we're going to create this directory structure
| | 01:56 | and import it into Subversion.
| | 01:58 | So we're going to go into the temp directory,
and we're going to make a directory called
| | 02:03 | r1-p1, and then we're going to go in there and
create the subdirectories, so it should look like that.
| | 02:16 | Now, we're going to import that into
Subversion by using svn import, and in this case, I'm not
| | 02:23 | going to put the -m because I'm going to
show you how the editor's invocation works
| | 02:27 | because we did that set SVN_EDITOR=notepad ,
and so here it's going to open up Notepad.
| | 02:33 | You'll see that there is a line that says
--This line, and those below, will be ignored--.
| | 02:37 | That shows you the status of
all the things you're doing.
| | 02:41 | Any line or lines you put
before that are your commit message.
| | 02:44 | So we're going to put Import structure of
project p1 and then when we save that and
| | 02:52 | quit Notepad, it automatically
adds it to the Subversion repository.
| | 02:58 | Now in our case, since we did it from a
temporary directory, we can go ahead and go back to
| | 03:02 | the root and delete that temporary directory.
| | 03:06 | And now finally, we want to change directory to
the place where we want the working set to live.
| | 03:11 | In this case, I'm going to do it at the
root of the C drive, but you may want to put it
| | 03:15 | inside of a directory called work or
div, or wherever you keep your source code.
| | 03:19 | Note that this is different than your
original directory if you had files in it.
| | 03:23 | You can put it in that same place, but
remember your original directory with files is not
| | 03:28 | part of Subversion, it's not
being tracked for source code control,
| | 03:31 | so you need to create a new directory using
Subversion that has not only your files, but
| | 03:36 | also some metadata that allows
Subversion to track your changes.
| | 03:40 | So in our case, we're going to svn co--now
CO is short for checkout. Subversion has long
| | 03:47 | and short versions of many of the
commands. In this case, CO stands for checkout.
| | 03:52 | Another one I'll use quite a bit is CI, which
is short for check in, which is actually short
| | 03:58 | for the Subversion commit command.
| | 04:00 | So we're going to check out our svn
repository 1, repository 1, project 1, and what this is
| | 04:07 | going to do is not only create a C:\r1-p1
directory, it's also going to collect all
| | 04:14 | the data from the repository, including any
files we had in the trunk directory and put
| | 04:19 | them in there and tell
Subversion to start tracking them.
| | 04:21 | So now if we go and cd to r1-p1, you can see that
there is our subdirectory structure that we wanted to have.
| | 04:30 | Now in order to be able to ask the Subversion
if it's really tracking this, we can say svn log -v,
| | 04:35 | and now we can see the entire log.
| | 04:40 | First, you'll see revision 2 says that
changed these paths, and so revision 1, we actually
| | 04:45 | created the subdirectory for project p1.
| | 04:49 | So that's all there is to
creating a repository and a project.
| | 04:53 | You can easily create additional projects
inside this repository, you simply skip the
| | 04:58 | first SVN admin command and then just start with the
svn mkdir command for creating your additional projects.
| | 05:06 | Let's move on to adding some files in
there and do some check ins and check outs.
| | 05:11 |
| | Collapse this transcript |
| Working with check-in, checkout, and revert| 00:00 | We've got a repository and a project
set up. Let's add a file and check it in.
| | 00:05 | Our working set is in the trunk directory,
so first we change to that directory and
| | 00:10 | then we'll create the file and
we're going to put in the following code.
| | 00:15 | The content is from the new
project haiku error messages page.
| | 00:19 | We're going to pick one that's happened to
all of us before we started using Version Control.
| | 00:22 | With searching comes loss and the presence
of absence, My Novel not found. All right.
| | 00:50 | So we save it, and now we're
going to add it to the repository.
| | 00:54 | But before we add it to the repository, let's ask
Subversion what's the status of the files in this directory.
| | 01:01 | You can see it doesn't know what to do with f1.c
because we have to tell it to add it to the repository.
| | 01:06 | So to add it, we type svn add f1.c, and then
if we run svn status again, you can see we
| | 01:14 | have a pending add for our file
that's not yet been checked in.
| | 01:17 | So to check it in, we're going to commit it,
we're going to type svn commit, and we're
| | 01:21 | going to put a commit message on
the command line here, Add f1.c.
| | 01:26 | Now, if we ask svn the status of this project,
we can see that all the files are checked in.
| | 01:30 | But if we want to look at the log, we can only see
the message that says, we imported the structure.
| | 01:37 | You might wonder what happened to my check in?
| | 01:39 | Well, with svn, in order to get the log up
to date, you need to run svn update command.
| | 01:45 | Now when we look at the log, you can see both the initial
creation of the directory and the addition of f1.c.
| | 01:53 | Now, if you look at the beginning of each
of the lines in the log, here, and here, you
| | 01:58 | can see the letter R followed by a number.
| | 02:01 | In Subversion, this is the
revision number or changeset ID.
| | 02:05 | So let's use Notepad to open up f1.c, and
then we'll change the words "My Novel" to
| | 02:11 | the word "Website".
Now we'll save the file.
| | 02:15 | Now we're going to check it in again, but
this time we'll use the editor feature to
| | 02:18 | add our commit message.
| | 02:19 | SVN has many shortcuts for its commands, and in this
case we'll use svn ci, which is a shortcut for commit.
| | 02:27 | As you saw before, CO is used for check-out,
so they had to use some other set of letters,
| | 02:32 | instead of using CO for commit,
they used CU, as in check in.
| | 02:37 | So we type this and Notepad opens.
| | 02:40 | You did remember to set your
SVN_EDITOR environment variable right?
| | 02:45 | If not, you got an error message at this point.
| | 02:47 | So set that environment variable now and rerun
this command in order to follow along from this state.
| | 02:53 | So in the editor that appears, in our case
it was Notepad, you might have set it up to
| | 02:57 | use your own favorite editor. We're going to add a
multi-line message, so Change "My Novel" to Website.
| | 03:08 | Change message to better
reflect product features.
| | 03:13 | And as we save this and exit, we can once
again run svn update, and then run svn log
| | 03:22 | and see here's our Import structure, our
Add f1.c, and our multi-line change message.
| | 03:30 | Now, when you're trying to hunt for A revision
number for some of the commands we're about
| | 03:34 | to use, this could get very, very
long with all of the change messages.
| | 03:38 | So the log file command has a way of allowing
you to see just the revision numbers and the times.
| | 03:43 | So if you type svn log -q, you get a listing
that just has one line for each revision or
| | 03:49 | changeset that's been checked in.
| | 03:51 | So now let's make another
change, and then we'll roll it back.
| | 03:55 | So once again, we're going to open up f1.c,
and we're going to change Website to Webpage.
| | 04:04 | In order to see the differences between our
most recent version in our working set, we
| | 04:07 | can use the svn diff command, and you can
see it shows that we're currently on revision 4
| | 04:13 | in the repository. This is our working copy,
and here this is essentially the line we deleted,
| | 04:19 | website not found, and this is the line we
added or essentially changed to Web page not found.
| | 04:24 | Now, svn diff shows the differences between all
the files in the working set and the repository.
| | 04:33 | So if we want to only see the differences
between one file in the current repository,
| | 04:37 | we can say svn diff f1.c.
| | 04:39 | Now in our case, it's going to be exactly
the same, because we only have one file.
| | 04:44 | You can also ask for the differences
between the working set and a specific version.
| | 04:48 | So for example, if we say svn diff and ask
for the distance between this and revision 3,
| | 04:53 | you can see that in revision 3 we had "My Novel"
and currently we have Webpage. All right.
| | 05:00 | Now, let's roll back to the topmost
revision, which is our most recent commit.
| | 05:05 | So we say svn revert and revert this file.
| | 05:10 | Now it's reverted. Now when we type it
out, you can see we're back to Website.
| | 05:15 | Finally, you can also revert to any revision, not
just the top revision by using the update command.
| | 05:21 | So let's go svn update, back to revision 3, and
when we type it out again, we're back to "My Novel".
| | 05:31 | Note, none of your changes in the repository
have been lost. Everything is all still there.
| | 05:38 | It's just the basic workflow of
being able to update the working set.
| | 05:41 | So for example, we could update back to revision 4
and get back to Website, and now we're back to Website.
| | 05:50 | Remember, none of your changes in the repository
have been lost. You're just updating your working set.
| | 05:55 | So that's the basic workflow of
check in, check out, and revert.
| | 06:00 | You'll also want to look at the Subversion
documentation to see how to delete files,
| | 06:04 | how to rename files, and how to move files
within directories and create other directories.
| | 06:09 | All right. Now, let's move on to tagging.
| | 06:14 |
| | Collapse this transcript |
| Tagging| 00:00 | As we learned earlier, tagging or
labeling is a key feature of version control.
| | 00:05 | It allows you to tag a complete set of
files so that you can get back to a known state
| | 00:11 | which will allows you, for example, to fix a
bug in a released version while you're working
| | 00:15 | on the next version.
Tagging in SVN is really easy.
| | 00:19 | We'll just move up one directory to the
parent and then tell SVN to make a copy, svn copy
| | 00:25 | from trunk to the tags
directory, and we'll call it v1.
| | 00:30 | Now if we run the status command, you can
see the svn thinks we want to create a v1
| | 00:35 | directory inside of tags and add f1c to that.
| | 00:40 | Our tagging is not complete as we still
have to commit the tag to the repository.
| | 00:48 | So if we do svn update and svn log, we can see now
that we have here at the top create tag for version 1.
| | 00:58 | And for the future if we do svn log and
pipe it into more, we'll be able to stop it so
| | 01:04 | that it doesn't scroll
off the top of the screen.
| | 01:06 | So here we can see the entire revision 5
where we're creating the tag for version 1.
| | 01:11 | Now go inside the tags directory, and
we'll go inside v1, and there is our f1.c.
| | 01:18 | All right, that's how easy it is to do tagging.
| | 01:20 | Now, any time you need to make updates,
you'll come back to this directory and be able to
| | 01:25 | make your changes right here.
| | 01:27 | And now this is separate from what's in your trunk
directory, so those two things now are completely independent.
| | 01:32 |
| | Collapse this transcript |
| Branching and merging| 00:00 | The last major piece of functionality we
need to explore is branching and merging.
| | 00:04 | In SVN, it's done much like tagging.
| | 00:08 | We create the branch from the common parent
directory, the one containing the trunk, tags
| | 00:11 | and branches by using svn copy.
| | 00:14 | So let's go back up to the parent directory,
make sure we're in the right place, there
| | 00:18 | we can see branches, tags, and trunk, and then
we'll execute the following command, svn copy
| | 00:23 | trunk branches\b1, our
branches are going to be called b1.
| | 00:30 | Once again, you can see this is pending,
it hasn't actually been created yet.
| | 00:36 | So we do a commit again and create branch b1.
| | 00:48 | Scroll off to the top of the
screen, once again log more.
| | 00:53 | There we see it, created
branch b1 that's revision 6.
| | 00:57 | Now you notice that SVN doesn't make a
distinction between your branches and the trunk in terms
| | 01:03 | of its revision numbers.
| | 01:05 | All updates go to the same list of
revisions, each with its own revision number.
| | 01:09 | This is because the revision number represents
revision of the entire repository, not just of a single file.
| | 01:16 | So, to work with the branch we have to
go into branches b1 and make an update.
| | 01:24 | So in this branch we'll add a method called
feature1, No more available space, Look to the cloud,
| | 01:38 | Your hard drive is full.
All right, and then we'll save this.
| | 01:45 | Now if we ask SVN for the status, you can
see that we've modified file f1.c and the
| | 01:53 | branches b1 directory.
| | 01:55 | If we switch back to the trunk directory and
ask SVN status, you can see it shows no changes,
| | 02:03 | so it's keeping these independently.
| | 02:05 | So now we'll switch back to
the branch, and we commit.
| | 02:16 | And then I'll update, and there is a
shortcut for SVN updates, just svn up.
| | 02:24 | And there we can see Branch b1: Added feature 1.
| | 02:28 | You might note that I put the words
branch b1 in front of the commit message.
| | 02:32 | That's because subversion doesn't track for you
which branch changes are made in, so therefore
| | 02:39 | a convention that's often used is
include the branch name in the update message.
| | 02:44 | So, let's quit this and talk about merging.
| | 02:50 | If you want to continue to work in a branch
for an extended period or time, you want to
| | 02:53 | do a forward integration from
the trunk from time to time.
| | 02:57 | That time varies based on how active the trunk
changes are if somebody is actually working there.
| | 03:02 | Usually, you do that weekly.
| | 03:03 | You do that so that your branch doesn't
get too far out of date with changes in other
| | 03:08 | areas of software that you're not working on.
| | 03:11 | But in our case, the trunk is just fine so
we're going to do just a reverse integration
| | 03:15 | from our branch and merge our
changes from the branch into the trunk.
| | 03:19 | So first, we're going to go look at the log to see
which range of changes are correspond to our branch.
| | 03:25 | So in our case, you can see we created our branch at
revision 6, now we added our update at revision 7.
| | 03:32 | So first we have to get back to the root
directory of our project and then we're going to use
| | 03:38 | the svn merge Command, so we tell it to merge
all the versions we have done in the branch.
| | 03:43 | So svn merge -r6:7 branches\b1 trunk.
| | 03:53 | As before note that this does not actually
record those changes in the repository, we
| | 03:58 | still have to check those in.
| | 04:00 | But now you can see instead of M for modified,
it has U for updated and from merging, and
| | 04:05 | it shows you that it's merging
and recorded a merge info for that.
| | 04:09 | So now we're going to say svn ci Merged
changes from branch\b1 into trunk, and there we can
| | 04:25 | see revision 8 we have merged
changes form branches b1 into trunk.
| | 04:29 | And our new feature is now in the trunk,
and we can prove that by going into the trunk
| | 04:34 | and typing out f1.c.
| | 04:36 | And you can see that we have both
our original change and the feature.
| | 04:40 | Okay, that's the basics
of branching and merging.
| | 04:44 | Obviously, you can get a lot more complicated
than that, and you can find yourself in situations
| | 04:48 | where there are conflicts, and you'll have to
manage them manually using differencing tools.
| | 04:53 | But it just shows you it's not hard to do
branches, and it's not difficult to merge
| | 04:57 | the changes back together if you
properly coordinate what it is you're doing.
| | 05:02 | Typically, there is going to be two different
kinds of branches. You're going to do either
| | 05:06 | a fix branch or a feature branch.
| | 05:09 | What we did here was a feature branch, but
sometimes you might just take the current
| | 05:13 | state of your product, make a branch in
order to a fix, and then merge that fix back into
| | 05:18 | the product while someone else continues on
working on the main branch to do future things.
| | 05:23 | All right, we're done with subversion in the
command-line, let's move on to taking a look
| | 05:27 | at subversion in shell
integration using TortoiseSVN.
| | 05:32 |
| | Collapse this transcript |
| Working with GUI clients and IDE integration| 00:00 | For the final part of our exploration of Subversion,
we'll use the TortoiseSVN Shell integration tool.
| | 00:07 | TortoiseSVN is free, and you can find the
link to download the installer in the Links.rtf
| | 00:13 | file in the Exercise File directory.
| | 00:15 | Here we have it on our
desktop, double-click on it.
| | 00:20 | TortoiseSVN, as I said, is a shell extension,
meaning there isn't going to be an icon that
| | 00:25 | you run it from. It runs all of the time,
anytime you have a Windows Explorer window open.
| | 00:31 | Remember, as I said, TortoiseSVN is free, but
the developers like to have your appreciation
| | 00:36 | and support. You can donate to them
by clicking on the Donate button there.
| | 00:40 | All right, we have it installed.
| | 00:43 | In order to get the icons in the Shell
integration fully operational, after you've installed
| | 00:48 | the TortoiseSVN tool, you have to do a reboot.
| | 00:52 | So let's go, go to the Computer, go here,
and we'll see now that there is a nice icon
| | 00:57 | right here on our project folder.
| | 01:00 | With TortoiseSVN, we can perform almost all
subversion functions right from inside the
| | 01:03 | Windows Explorer using the
right-click Context menu.
| | 01:07 | Note that this does slow down the display
of the Context menu just a little bit, as
| | 01:11 | it queries the repository behind
the scenes every time you right-click.
| | 01:15 | But the power you get in
exchange is substantial.
| | 01:18 | So let's go ahead and open up this directory, and
we'll open up the trunk directory and look around.
| | 01:24 | The first thing you can see is that our file f1.c
has a nice check mark icon inside of a green circle.
| | 01:31 | This means that TortoiseSVN has queried the
repository and shows us that the status of
| | 01:36 | this file is checked in and up to date.
So, let's open it up and make one more change.
| | 01:42 | We're going to add ellipses to he
end of the word cloud and save it.
| | 01:49 | Note now that the icon on f1.c has changed to
an exclamation point inside a red circle,
| | 01:55 | indicating the file has uncommitted changes.
| | 01:57 | To commit, we simply right-click again, come
down here and select SVN Commit, and you can
| | 02:03 | see that TortoiseSVN has its
own built-in Commit Editor.
| | 02:07 | And it doesn't use the value of SVN underbar
editor the environment variable we set before,
| | 02:13 | so let's add a message and then we'll save it.
| | 02:18 | It automatically runs the commit now and
shows us the log at that particular spot.
| | 02:23 | Once we click OK here, you notice the icon
returns back to the white check mark inside
| | 02:29 | of the green circle.
| | 02:31 | If we explore the TortoiseSVN fly-out menu,
you can see that you can perform Diffs, Show
| | 02:36 | the Log, Browse the whole Repository, perform
Updates, Deletes, Locks and even Branch and Merge.
| | 02:43 | As our last exploration of this, however,
let's select the Blame command and see it was made
| | 02:46 | changes to our files.
| | 02:50 | You can see that the Blame dialog opens, and
you can select a range of revision you wish
| | 02:53 | to examine and get some diff options.
| | 02:55 | In our case, let's just
click OK and see what we get.
| | 02:59 | So you can see that in this case, of course
I made all of the changes here, but you can
| | 03:03 | see the revision number in each line over here,
and you can see the section here indicates
| | 03:09 | this is the most recent set of changes.
| | 03:12 | So you can see exactly what it is that's happening
with the file in its current state in the repository.
| | 03:18 | One last note, if you remember back to the
command line section, all of the URIs I used
| | 03:23 | to describe where the repository was
or the form file:///c:/SVN and so forth.
| | 03:32 | Those are URIs, which means
you're using a local repository.
| | 03:36 | If you are using a remote repository, you
would substitute either an http or https URI or
| | 03:44 | even one that says SSH depending on the protocol
and the location point of the remote repository
| | 03:50 | that you're actually using.
So, that's our tour around subversion.
| | 03:54 | There is many more features but these are the essential
things you need to know to use subversion day to day.
| | 04:03 |
| | Collapse this transcript |
|
|
5. PerforceInstallation and setup| 00:00 | All right, let's take a look at Perforce.
| | 00:03 | Perforce is a centralized version control system
with a new distributed add-on called Git Fusion.
| | 00:09 | We're only going to locate the centralized
version because Git Fusion actually requires
| | 00:13 | a separate server in order to run it.
| | 00:15 | Whether it's virtualized or real, it allows
you to use Git as a front end for Perforce.
| | 00:21 | For up to 20 users or 20
workspaces, Perforce is free.
| | 00:24 | And of course then there are commercial
licenses which I believe are sold on a per seat basis.
| | 00:30 | There's also a cloud-based version
that you can use in the trial basis.
| | 00:34 | And you can find that to
link you see here on the screen.
| | 00:36 | This link will also live in the Links.rtf
file in the exercise files folder. And also
| | 00:42 | here's the link to download the local version that
gives you that up to 20 users 20 workspaces for free.
| | 00:51 | So let's move on and install the
Perforce Server and the Perforce client.
| | 00:56 |
| | Collapse this transcript |
| Working with check-in, checkout, and revert| 00:00 | Okay, we've got Perforce and all of its tools
installed, but unlike some of the other tools
| | 00:05 | we're using in this course, Perforce works
directly with the file system as opposed to
| | 00:10 | having the GUI client be integrated and
automatically create folders and files from inside that client.
| | 00:16 | So what we need to do now is open the
Windows Explorer and switch to our Work directory.
| | 00:24 | And inside here, we're going to create a
directory within a workspace called p1.
| | 00:31 | Now if we switch back to the Perforce client,
you don't see it yet, but once we click this,
| | 00:35 | Refresh, there is our folder p1.
| | 00:38 | Perforce manages files, not folders, meaning
we have to actually create a file in order
| | 00:43 | to get Perforce to add this folder to our workspace.
| | 00:47 | So we'll come back here, we'll go inside p1,
and we'll right-click and say New Text File,
| | 00:52 | and we'll put in ReadMe.txt.
| | 00:56 | Doesn't have to have anything in it. In our
case, let's come back to Perforce, refresh
| | 01:01 | again, and now we open up
p1, you can see ReadMe.txt.
| | 01:06 | You can notice that this has blank icon that means
that Perforce recognizes that that's not in the depot.
| | 01:12 | The way we add it to the depot is we
right-click on it, and we say Mark for Add.
| | 01:17 | Perforce can have a whole bunch of pending
changes lists. You can have something you're
| | 01:21 | working on over here and something you're
working on over there and the default change list.
| | 01:26 | For everything we're doing in the course,
we're going to use the default change list, so I'm
| | 01:29 | just going to click
Don't show this dialog again.
| | 01:32 | But you can create multiple change lists if
you want to be working on certain things and
| | 01:36 | hold back changes and not
check them in until you're ready.
| | 01:40 | But in our case, we're going to be checking
in the changes every time we make a change.
| | 01:44 | All right, now that we've marked
that for add, we can see a few things.
| | 01:50 | First of all, down here at the bottom, you can see
the fact that this in fact has been marked for add.
| | 01:57 | This is actually the command-line version
of that command, and you can see what I meant
| | 02:00 | about the fact that there is all these complicated
flags in order to simply just add a file to the repository.
| | 02:07 | You can also see over here in the Details
pane where the actual file is, where it's going
| | 02:12 | to go on the repository, which revision it
is the date and time, the type of the file
| | 02:18 | and which kind of file Perforce thinks it is.
| | 02:21 | Perforce's file types have to do, whether
they're text or binary, so that knows which kinds of
| | 02:25 | different thing to do when
doing differencing and merging.
| | 02:29 | So we've got our file, it's got now a text icon,
and it's got a plus, meaning it's marked for add.
| | 02:35 | And so let's go ahead and add that in
to the repository, and we'll say Submit.
| | 02:41 | And this is the Changelist Submit dialog
we're going to say Create folder p1 with ReadMe.
| | 02:49 | And we'll say Submit, and now you can see we
have a nice little green dot there indicating
| | 02:55 | that it's up to date in the repository,
and our working set has the latest version.
| | 03:01 | Now let's add some code and
understand the lifecycle working with Perforce.
| | 03:05 | The content we're going to use is from
the new project's Haiku Error Messages page.
| | 03:09 | These aren't actual Haikus,
but they kind of feel like one.
| | 03:12 | We're going to pick one that's happened to us
all before we started using version control.
| | 03:16 | Again, we have to create files by using the
Windows File Explorer or our Text Editor, not Perforce.
| | 03:24 | So we come back here, we'll right-click once
again and say New Text Document, and I'm going
| | 03:29 | to call this thing f1.c.
| | 03:34 | And Windows is very kind and asks us if we
want to make sure we got the right kind of
| | 03:37 | file, because it will decide to open Visual
Studio when we double-click on this to edit
| | 03:43 | it, so we're going to go ahead and do that.
| | 03:48 | In this case, f1.c is going to say main () printf
With searching comes loss, and the
| | 04:04 | presence of absence, My Novel\" not found.
With Visual Studio we can simply
| | 04:21 | click Save All, and that saves the file,
and now we can switch back to Perforce and add
| | 04:28 | it to the repository, come back to our workspace,
refresh it once again, now we can see the file.
| | 04:37 | Once again we have a plain icon, we will right-click,
Mark for Add, and then we'll Submit, and we'll
| | 04:46 | say Initial Commit of f1.c.
| | 04:53 | Once again, we can see all the command line
operations down here in the log.
| | 04:57 | Now, to see the history of what we've done
so far, we can right-click on our p1 folder
| | 05:03 | in the workspace and select Folder History.
| | 05:06 | And now you can see the list of
Changelists we've done with this folder.
| | 05:10 | Changelist 1 we created the p1
folder by adding the read me ReadMe.
| | 05:14 | Changelist 2, we did an initial commit of p1.
| | 05:18 | Unlike SVN and Git and Mercurial, Perforce is
a locking version control system, so before
| | 05:23 | we can edit this we have to check it out.
| | 05:25 | You notice we have a green dot but we don't
have anything that tells us we can edit it.
| | 05:30 | So with Perforce you have to
right-click here and say Check Out.
| | 05:34 | Now you can also do Check Out and Open if
you want to open with the default tools, so
| | 05:39 | we'll just do that, Check Out and Open.
| | 05:41 | Once again, it opens Visual Studio. Now let's
change My Novel to a more modern error message.
| | 05:47 | We'll say Website not found.
| | 05:49 | And we'll save it, and we'll Exit Visual Studio,
and now you can see it shows here in the History
| | 05:56 | that f1.c is pending a change, and
let's save that file and check it in again.
| | 06:02 | So once again, we'll do a Submit, and we'll
say Change My Novel to Website and submit it.
| | 06:14 | Now we might want to look at the history
of the file, so what we can do now is we can
| | 06:18 | come down here and say File History, and
over here, since we have the History window open,
| | 06:28 | we can see that here's the
file history of the file.
| | 06:31 | So if we select these two lines together
and say Diff Selected, it'll open up Diff tool
| | 06:38 | and show us the changes we've just made.
| | 06:44 | One of the cool tools that Perforce has
is something called the Time-lapse View.
| | 06:48 | Now right now it's only going to show two
different versions, but here is version 1,
| | 06:54 | there's version 2, and if we had more--
which we'll see later--we'll actually be able to
| | 06:58 | see the file as it changes over time.
| | 07:02 | All right, now we're
going to make one more change.
| | 07:04 | Again, we're going to Check Out and Open,
and we're going to change Website to Webpage,
| | 07:11 | Save it and Exit Visual Studio.
| | 07:13 | And now again, we're going to Diff this
against what they call the Have Revision, which is
| | 07:18 | the Head Revision, and you can see what's
in the depot here. This is the depot side
| | 07:23 | with the purple triangle as Website, and
what we haven't checked in is web page.
| | 07:28 | But remember we have saved it, so now
we're going to do is we're going to revert.
| | 07:33 | We're going to right-click here and Revert.
| | 07:36 | Now the Revert dialog says
what are we going to revert.
| | 07:39 | In this case, we're going to Revert our edit.
| | 07:42 | We right-click here, and now if we go and
Diff this against the Have version, you're
| | 07:47 | going to see that it says Website in both
cases because we've updated our workspace
| | 07:52 | with the content that we had originally.
| | 07:55 | All right, now we reverted
to a particular version.
| | 08:01 | Now if we want to actually revert to a
specific version, for example, we can come back here
| | 08:05 | to the initial version and right-click
on here and say Rollback to Revision.
| | 08:12 | This is going to allow us to
roll back to anything that we want to.
| | 08:16 | So for example, we could roll back to the
previous version, or we can roll back to a
| | 08:19 | specific revision, we can roll back to a
specific changelist, a Date and a Time or a Label.
| | 08:25 | So you've got a very flexible
manipulation of files within Perforce.
| | 08:30 | So in this case, we're going to roll back to
Revision 1, and they give you a predefined
| | 08:37 | changelist description. We're going to run
it, and now we're going just kind of come
| | 08:41 | down here and Open this up and
see that we're back to My Novel.
| | 08:48 | Now remember, all the different versions are still
inside the repository. You haven't lost anything.
| | 08:54 | So for example, if we come back here and
we do another rollback, we can roll back to
| | 09:04 | the Changelist, and we can browse for the
Changelist and go all the way back to Change
| | 09:09 | My Novel to Website and submit that.
| | 09:16 | And now when we Open the file
you can see we're back to Website.
| | 09:23 | So that's the basic workflow for using check-ins
and check-outs and reversion and rollback in Perforce.
| | 09:28 | Now let's move on to tagging, which is called
labeling in Perforce, and see how we can use that.
| | 09:33 |
| | Collapse this transcript |
| Tagging| 00:00 | Tagging, or creating a human readable label
for a current state of a repository in Perforce
| | 00:05 | is called Labeling, and it's really easy.
| | 00:08 | We'll just go to our folder p1, right-click, go
down to the Label menu, and up comes the Label dialog.
| | 00:15 | In this case we'll put in our Label, we'll
say it's v1, and we'll automatically apply
| | 00:20 | the label to the file revisions of the things
inside Work\p1 at the latest revision and click Label.
| | 00:26 | And it says This label
doesn't exist. Create it?
| | 00:30 | Yep, that's what we want.
| | 00:32 | Now labels are suitable for rollbacks, and we
can see that by starting the rollback process
| | 00:36 | here for this file, and if we dropdown Rollback
file to: we can pick label, and when we browse.
| | 00:45 | There is our v1 label.
| | 00:46 | So this is the way in which you switch
between different versions when you want to roll back
| | 00:50 | and make a change and then roll forward
toward to where you were to continue on working.
| | 00:55 | And that's it for labeling in
Perforce. It's really that easy.
| | 00:59 | So we're not going to actually roll back anything
because we're already at the most recent version.
| | 01:03 | So let's move on to
Branching and Merging in perforce.
| | 01:08 |
| | Collapse this transcript |
| Branching and merging| 00:00 | The last major piece of functionality we're
going to do with Perforce is branching and merging.
| | 00:04 | You branch by right-clicking on your
folder, in this case, and selecting Branch.
| | 00:13 | Now Perforce does branching in the depot, not with the
physical folders, but within folders within the depot.
| | 00:20 | So what we're going to do is decide
where we want to put our branch folder.
| | 00:25 | And because it's not a physical folder,
it's not a good idea to put your branch inside
| | 00:30 | the folder with your main branch.
| | 00:32 | You want to put it within the depot
perhaps as a peer of your main branch.
| | 00:36 | So here's our source, depot/p1, and our
target isn't going to be depot/p1, say b1 here.
| | 00:44 | We're actually we're going to put it up here.
We're going to say -branch1/, and after we do the
| | 00:50 | branch we said automatically
submit after branching the files.
| | 00:53 | We're going to go take a look at the depot, and
when we refresh it we see that we now have two
| | 00:59 | different sets of folders in our depot.
| | 01:03 | And these files are different, we haven't
created two separate folders in our workspace,
| | 01:09 | but we just have two
separate folders in our depot.
| | 01:12 | So if we want to edit the file in the
branch, we can go here Check Out and Open, and now
| | 01:19 | we'll add a new feature, feature1, No
more available space, Look to the cloud,
| | 01:34 | Your hard drive is full, and
we'll Save and Exit Visual Studio.
| | 01:49 | Again, you can see the files in the repository.
The file has the check box, meaning we've checked
| | 01:55 | it out into the default changelist, and
now we're going to go ahead and submit that.
| | 01:59 | Now we're going to say Added feature 1, and
now it's all set up, and we're back in that
| | 02:08 | particular branch's changelist.
| | 02:11 | If you continue to work in a branch for an
extended period of time ,you want to do a forward
| | 02:15 | integration from the mainline
to your branch from time to time.
| | 02:19 | Remember, a forward integration means copying
changes from the main into your private branch
| | 02:24 | so that your branch doesn't get too far out
of date for those portions of your code which
| | 02:28 | you are not working on in the branch.
| | 02:30 | That means if you're working on a team
and other people, they are making changes, you may want
| | 02:34 | to take their changes as you're continuing
to work on your features to make sure that
| | 02:38 | both your features don't conflict with
theirs and your features may depend upon working
| | 02:43 | with their features
before you can check back in.
| | 02:45 | In our case, we're just going to do a
reverse integration and merge the changes from our
| | 02:49 | branch back into the trunk.
| | 02:52 | The way we do that is we right-click on the
branch folder, and we select Merge/Integrate.
| | 03:00 | Now the Source of our merge is our branch.
| | 03:02 | The target of our merge
is going to be back to p1.
| | 03:08 | Now we're going to go ahead and open up the
Options here in order to click this, Automatically
| | 03:13 | resolve files after merging.
That way it's a very simple merge process.
| | 03:18 | If you want it to do the merge and then have
to run the Merge tool to make that you have
| | 03:23 | checked exactly what's being merged,
you can do that by not checking that box.
| | 03:28 | But in this case, we're going to click Merge,
and you'll see now that says this file has
| | 03:34 | been merged, and it's been marked for integrate but
the change has not yet been saved back to the repository.
| | 03:40 | So we'll open up our changelist Pending window, and
you see now we have Merging depot branch back to p1.
| | 03:46 | And we'll right-click on that and say Submit.
| | 03:50 | It gives us an automatic message here. We could
create a more sophisticated one, but we'll submit that.
| | 03:55 | And if we now come back here and say Open f1,
you can see we have both our main and our feature.
| | 04:02 | So the Merge has been successful, we've
taken things from the branch1 and inserted them
| | 04:08 | back into the main trunk, and so now
everything is back together again.
| | 04:13 | And that's Branching and Merging in Perforce.
| | 04:14 | We're going to take one quick peek at one
more thing before we leave this chapter, and
| | 04:20 | that is just note that installing the
Perforce GUI also does give you a show integration
| | 04:25 | menu that allows you to do additional things.
| | 04:28 | Once you become much more experienced in working with
Perforce, this can save you some time in the future.
| | 04:35 | And that's it for
version control with Perforce.
| | 04:40 |
| | Collapse this transcript |
|
|
6. Microsoft Team Foundation Server (TFS)Installation and setup| 00:00 | Time to roll up our sleeves and dig
into Microsoft Team Foundation Server.
| | 00:05 | Microsoft Team Foundation Server is a
centralized revision control system. This means that there
| | 00:09 | is a server with an actual database that
holds your repository and all of your projects.
| | 00:15 | There are two versions. There is the full
on TFS, which requires an installation of full
| | 00:21 | SQL Server and has to be run on a Windows
Server Installation, and that's great for
| | 00:25 | enterprises and large groups.
| | 00:28 | There's also a free for open-source
hosted version at codeplex.com.
| | 00:34 | And just recently, Microsoft introduced the
Team Foundation Server Express Edition 2012,
| | 00:38 | another one of those great names
which is free for up to five users.
| | 00:43 | It's something you can download and install,
and it requires installation of SQL Server
| | 00:48 | Express, but that's something that you get
with Visual Studio 2010 and Visual Studio 2012.
| | 00:53 | There is also a number of commercial companies
which host TFS installations, including discount
| | 01:00 | ASP which has a 30 days free for five users and then
fairly reasonable fees for hosting a TFS installation.
| | 01:07 | For this chapter we're going to install the Team
Foundation Server Express 2012, abbreviated TFS.
| | 01:14 | You can just as easily work through this chapter
using the free TFS server on codeplex or your
| | 01:19 | own full installation of TFS.
| | 01:22 | The link of installation binaries and the
Links.rtf file in the Exercise's directory.
| | 01:27 | The installation of Team Foundation Server
Express 2012 is straightforward; however, you
| | 01:33 | may run into an issue with SQL Server
permissions if you've had a previous version of Visual
| | 01:38 | Studio or SQL Server installed
on your development machine.
| | 01:41 | There's a link in the Links.rtf file to a page
where you can download a script to fix this issue.
| | 01:47 | The installation of TFS Express is
essentially hands-off and takes about 30 minutes, so
| | 01:52 | we're not going to do a full walk-through.
| | 01:54 | Also, while some TFS functionality can be done
from the command line, the real TFS experience
| | 02:00 | is within Visual Studio.
| | 02:02 | So we'll be doing everything for
TFS using the Visual Studio GUI.
| | 02:06 | So let's fire up Visual Studio and make sure that
we've got Team Foundation Server properly installed.
| | 02:13 | To validate that you've got TFS installed
you can see that you've got the TEAM menu.
| | 02:18 | So we selected TEAM menu and select
Connect to Team Foundation Server.
| | 02:23 | Here you can see this is a list of
team project collections and projects.
| | 02:27 | We don't have any servers installed yet, so
we're going to click the Servers button, then
| | 02:31 | we're going to click Add, then we're going
to enter the name of the machine on which
| | 02:35 | the TFS Server is installed.
In our case here, it's car-booth-06-pc.
| | 02:42 | By default, TFS works on a TFS PATH
and a Port Number of 8080 and over HTTP.
| | 02:49 | Your administrator may have additional settings for you here,
different Port Numbers, different Paths, use of HTTPS.
| | 02:57 | Check and ask your administrator for the URL
of your Team Foundation Server if you're using
| | 03:01 | something other than the
Team Foundation Server Express.
| | 03:05 | If you're using codeplex, go to the Source
Code Control Tab and select the Source Code
| | 03:10 | Control, connect information, and it will
give you an HTTP URL and the User ID and Password
| | 03:17 | that you'll need to connect to
the TFS instance on codeplex.
| | 03:20 | So over here, we're just going to click OK
and then we're going to click Close, and now
| | 03:26 | you can see we've got Team Foundation Server,
and it has a default collection, so from that
| | 03:31 | point of view, we're good to go.
| | 03:33 | So we'll click Connect, and now
we see the Team Explorer - Home.
| | 03:37 | So that's it for our TFS setup. Now let's
move on to creating a team project and then
| | 03:42 | creating some projects to
check in to our TFS instance.
| | 03:47 |
| | Collapse this transcript |
| Creating a repository and a project| 00:01 | All right, let's get ready to create
some projects inside the TFS.
| | 00:04 | There is only one repository in TFS,
and that's on a machine-by-machine basis.
| | 00:09 | The way to create projects inside TFS is
first you have to create a team project and then
| | 00:13 | you create folders which hold your
individual projects and branches.
| | 00:18 | So first, we are going to create a team project,
click there, and we will give it a name so
| | 00:22 | we will call it TFS1 and description of our
project is TFS Team Project for Fundamentals
| | 00:31 | of Software Version Control.
| | 00:34 | We will click Next and with TFS you
always have to pick a Process Template.
| | 00:40 | TFS comes out of the box with three Process
Templates, Visual Studio Scrum, Agile Software
| | 00:46 | Development 6.0 and MSF for CMMI.
| | 00:50 | We are going to pick Visual Studio Scrum because
we are not going to be using all of the features
| | 00:54 | of Team Foundation Server, which has to do
with how do you use the work items and how
| | 00:59 | to you use the reporting facilities, and so
that's what these templates define, they define
| | 01:04 | work items, they define specific fields, inside
the work items for use with Scrum or Agile or CMMI.
| | 01:10 | In our case, we are simply going to pick Scrum.
| | 01:13 | If you want additional process templates,
you can click on this link and Microsoft has a
| | 01:18 | whole library of certified Process Templates.
So we are going to pick Scrum, click Next.
| | 01:23 | Now we are not going to branch from any other
existing source control so we are just going
| | 01:28 | to click here, and there is our settings
that we want to confirm. Yes, we want to call it
| | 01:34 | TFS1, that's our description, we are going
to use the Scrum template, and we are going
| | 01:39 | to create a new empty folder with TFS1
at the root, click Finish. All right.
| | 01:44 | We have successfully created our team project,
TFS1 on our default collection of the TFS repository.
| | 01:51 | So we are going to close this, and we are getting
ready to create our first actual set of folders.
| | 01:57 | In this chapter, we are going to use C#
instead of C for our sample code. It is easily
| | 02:02 | adapted from our examples we have done
before, and Visual Studio's TFS integration is very
| | 02:06 | easy to see and use using C#.
| | 02:09 | So we will come over here to the Start page,
we will click New Project, and we are going
| | 02:14 | to pick Console Application, and we are
going to put this in a directory we are going to
| | 02:18 | call c:\FSVC1, and we'll call the Solution name.
| | 02:25 | We are not going to automatically add it to
source code control because I want to show
| | 02:28 | you how to add some of the source code
control if you already have an existing solution.
| | 02:33 | So we will just click OK here
and up pops our main Program.cs.
| | 02:39 | We are going to close that because we are
going to use different files and here we now
| | 02:43 | we can see in the Team Explorer that we
can look at the Source Code Control Explorer,
| | 02:47 | so we are going to do that, and now you can see here,
here is our root repository, here's our team project.
| | 02:55 | All we have is the BuildProcessTemplates
under that, we don't have any folders, but we are
| | 02:58 | about to create that.
| | 03:00 | You can also now see that here is the local
path for where this stuff is stored for the
| | 03:04 | repository, not for the folder.
So let's go back to the Solution Explorer.
| | 03:08 | Here is our typical Solution Explorer for
C# project. We are going to get rid of
| | 03:13 | Properties here in visual studio.
| | 03:15 | What you don't see is this column right here,
the blank column, is where Source code control
| | 03:21 | information such as, "Is it checked in?", "Is it
modified?", and so forth is going to appear.
| | 03:25 | So the way we get stared with that is we
right-click on the Solution node and select this,
| | 03:30 | Add Solution to Source Control, the Add
Solution to Source Control dialog pops up and asks
| | 03:36 | us where we want to store our
solution inside the TFS server.
| | 03:40 | In this case, we want to put it inside our
TFS1 team project, and we are going to have
| | 03:45 | a solution folder. We are going to not
name it Console Application 1, we are going to
| | 03:49 | call it TFSSample, and we are going to click OK.
And now we can see a few things.
| | 03:55 | Inside our TFS team project, we
now have a folder called TFSSample.
| | 04:00 | Now this is conceptually the same as a Git
repository, a Mercurial repository or an SVN
| | 04:07 | repository, that particular folder.
| | 04:09 | As we do additional operations, we
will all be operating inside that folder.
| | 04:13 | You can see this green plus here indicates
that this particular folder has been created
| | 04:18 | and associated with this
repository but not yet checked in.
| | 04:22 | So we open it up here, we can see inside this
folder is our ConsoleApplication, inside that
| | 04:27 | is the Properties folder.
| | 04:30 | The Folders column only shows
folders, not the actual files.
| | 04:34 | Over here if we look inside the Files, you can
see here are all the files that are associated
| | 04:40 | with that particular thing.
| | 04:41 | And note now that this TFSSample folder is
exactly where we told it to be, inside the
| | 04:47 | FSVC1 folder and the ConsoleApplication
folder was created by the new Project Template to
| | 04:54 | hold the rest of our files.
| | 04:55 | We have got everything set up,
now let's check in our changes.
| | 04:58 | To do that, initially here
we come to the Team Explorer.
| | 05:01 | You can see here are our Pending Changes.
| | 05:03 | We are going to enter in the
Comment and click the Check In button.
| | 05:09 | Visual studio will give you this Check-in
Confirmation dialog every time you check in if you want.
| | 05:14 | In our case, I am going to click the Don't
prompt again because I am going to assume
| | 05:17 | that I know when I am checking in what it
is I want to change, or I can also look at
| | 05:21 | this Pending Changes dialog at any time. All right.
| | 05:25 | Now you can see Changeset
10 successfully checked in.
| | 05:28 | Your numbers may vary.
It might be Changeset 1 when you first do that.
| | 05:33 | We did a little bit of a setup on the
system to verify TFS is working before we started
| | 05:37 | to record this chapter, but that's the
Changeset number, and TFS uses the word Changeset to
| | 05:42 | identify things and uses numbers.
| | 05:45 | So now you can see all of
our green plus signs are gone.
| | 05:48 | Come back to the Solution Explorer, there is now a
blue lock indicating that the files are checked in.
| | 05:54 | So the Solution Explorer acts very similar
to shell integration that you might see in
| | 05:59 | other Source code control systems.
So that's it.
| | 06:03 | We have got our team project created,
we've got our Visual Studio project created, we
| | 06:07 | have got our folders created, we've got
our initial stuff checked in, let's get on to
| | 06:11 | making some changes and checking in
and checking out and looking at history.
| | 06:16 |
| | Collapse this transcript |
| Working with check-in, checkout, and revert| 00:00 | Okay, we've got a repository, we've got a
project, we've got a Visual Studio project,
| | 00:05 | let's add some files and check it in.
| | 00:07 | So in this case, we're going to right-click
on the project here and come down to the
| | 00:10 | Add menu and select Add > Class, and we're going
to call this class f1.cs, and here's our class.
| | 00:18 | So inside our class, we're
going to add a function.
| | 00:20 | The content is from the new
project's Haiku error message page.
| | 00:24 | We're going to pick one that's happened to all
of us before we started using Version Control.
| | 00:27 | So let's come down here and add void func1 (),
and we will use Console.WriteLine, which is
| | 00:37 | the C# equivalent of printf, With searching comes loss,
and the presence of absence, My novel\" not found.
| | 00:56 | Now let's look at the Solution Explorer
and see what Visual Studio is telling us.
| | 01:01 | We can see for ConsoleApplication1, there's
a red check mark next to it. That means that
| | 01:06 | file has been updated and
still needs to be checked in.
| | 01:10 | You can see that f1.cs has a green plus
sign next to it. That means that's a file to be
| | 01:17 | added to Version Control,
but not yet checked in.
| | 01:19 | And as we saw before, for example, Program.cs
has a little blue lock icon next to it, which
| | 01:26 | means it's checked in, it's read-only in your
working set until you start making some changes
| | 01:31 | to it, which also means that your working set
for that file is up to date with your repository.
| | 01:36 | So in order to check this in, we're going to
come over here and right-click on the project
| | 01:41 | line, ConsoleApplication1, and then
we're going to select Check In from the menu.
| | 01:46 | Visual Studio of course always requires you to save
everything before you check it in, so we'll say Yes.
| | 01:51 | Now it brings us back to
the Pending Changes tab.
| | 01:54 | So we can see a number of things here.
| | 01:56 | We can see we're in our Team Project TFS1, and you
can see exactly all the details when I hover over that.
| | 02:03 | You can see that there are two changes here,
and you can see this tree, this shows which
| | 02:09 | files are being changed.
| | 02:10 | You can see that ConsoleApplication1.csproj
is being updated, and f1.cs is being added.
| | 02:18 | So in our Comments, we're going to say Add
Func1, and then we're going to click the Check
| | 02:24 | In button, and now we see
Changeset 11 successfully checked in.
| | 02:28 | Let's go back to our Source Code Control Explorer and
look a little bit at the status of what's going on here.
| | 02:33 | We can come to this folder now and
right-click and say View History.
| | 02:38 | Now we can see for, as we did with Git in
our initial run-through, this is essentially
| | 02:42 | the same as a Git log, so here at
Changeset 10, we did an Initial Commit, Changeset 11,
| | 02:49 | we added function 1.
| | 02:50 | You can right-click here and ask for
Changeset Details, and over here you'll see we added
| | 02:56 | f1.cs and updated csproj.
| | 03:00 | If we click on this one and say Changeset
Details, the Team Explorer now shows us the
| | 03:06 | fact that we added all these files.
So let's close the History pane.
| | 03:10 | Let's go back to our f1.cs, and
let's go back to our Solution Explorer.
| | 03:15 | So let's make a change so that
we can see versioning in action.
| | 03:18 | So we're going to open this file again,
and we're going to make a change, we're going
| | 03:21 | to change the string My Novel to Website.
Now we're going to save the file.
| | 03:29 | This button here saves the individual file,
this button here saves everything, so I tend
| | 03:33 | to get into a habit of clicking this Save All
before I do Source Code Control operations
| | 03:38 | in order to save me all those
dialogues of, oops, you forgot to save that.
| | 03:42 | So once again, we'll come over
here, right-click, and say Check In.
| | 03:46 | Once again, the Pending Changes dialog pops
up, and we're going to say Changed My Novel
| | 03:52 | to Website and click Check In.
| | 03:55 | But before we click Check In, I want to
make a note of something that TFS does uniquely
| | 04:00 | from some of the other
Source Code Control systems.
| | 04:03 | Because TFS locks the files, when you check
them out to edit, sometimes somebody needs
| | 04:08 | to go in and make a change to a file before
you're ready to check in, and when you need
| | 04:12 | to do that, what you do is
you use this Shelve feature.
| | 04:16 | So the Shelve feature allows you to preserve
your Pending Changes and add this to what's
| | 04:22 | called a Shelf Set, which is
essentially a temporary Check In, so all your work is
| | 04:26 | saved in the central server, but the
mainline is not physically changed so that someone
| | 04:31 | else can check that out and make their changes.
| | 04:34 | So in this case, we're not going to do
a Shelve, we're going to click Cancel.
| | 04:38 | We're going to come back and actually do the
check in, but that feature can be incredibly
| | 04:42 | handy when you have a system like this, which has
a centralized server, and file locking. All right.
| | 04:48 | Now we've got Changeset 12 checked in.
| | 04:50 | Once again, we'll come back to the Source
Code Control Explorer and ask for History,
| | 04:55 | and there you can see, here is our initial
Changeset, Add Func1, Changed My Novel to Website.
| | 05:02 | If we select two Changesets, for example, 12
and 11, we can now right-click and say Compare.
| | 05:09 | This dialog pops up because you get all kinds
of options when doing compares, we won't get
| | 05:14 | into all the details of that, but this
also can work when you've got lots and lots of
| | 05:18 | files, you can filter by
specific file types and so forth.
| | 05:22 | In this case, we're just going to click OK
and look at the differences, and you can see,
| | 05:26 | ah, these two things are different.
| | 05:28 | And if we compare the files now, it will
actually give us a visual comparison, and we can see
| | 05:34 | that My Novel got changed to Website.
| | 05:37 | Note that a Changeset, of course, can contain
potentially hundreds of files or thousands
| | 05:40 | of files, if you've been
working on it for days and weeks.
| | 05:44 | So the Changeset first gives you the level
of folder differences, because you might have
| | 05:50 | additional folders being added and deleted,
and then once you've come to that level, as.
| | 05:54 | As we saw back here, you can
actually then compare individual files.
| | 05:59 | So we'll close this and
we'll close this and continue on.
| | 06:04 | Now, let's make another change.
| | 06:06 | We'll close the History, come back to our file,
and we're going to change Website to Webpage.
| | 06:13 | Now, we're not going to check it in, but we
are going to try to ask for the differences.
| | 06:17 | So we're going to come back to the Solution
Explorer, and we're going to right-click here,
| | 06:22 | and we're going to compare, and we're
going to compare our Workspace Version with the
| | 06:27 | Latest Version, so we click OK.
| | 06:30 | And again, we get the visual differencing
window here, and you can see that it says
| | 06:36 | that the server version has Website and our currently
updated version that's not yet checked in has Webpage.
| | 06:42 | So in this case, in order to revert this,
all we have to do is close this and come back
| | 06:46 | to Visual Studio and say Undo.
| | 06:49 | Now, let's go ahead and update
that again to Webpage and save it.
| | 06:56 | So if we look over in the Solution Explorer, we can
see that f1.cs now has a red check mark next to it.
| | 07:01 | But what if we decided after we've saved it
in our local working set, but before we've
| | 07:06 | checked it into TFS, that this
isn't really what we want to do?
| | 07:09 | Well, you can come over here, right-click
on the file, come down to the Source Code
| | 07:13 | Control menu, and say Undo Pending Changes.
| | 07:17 | You will get this dialog that says this is
going to undo all pending source changes for
| | 07:21 | that particular file or
files that you've selected.
| | 07:23 | I'm going to click Undo Changes, and it
says Undo check-out and discard changes?
| | 07:28 | I'm going to say Yes to All, and now you can
see that Webpage has now been reverted to Website.
| | 07:34 | Remember, none of your changes in the repository
have been lost. You're just updating the working set.
| | 07:39 | If we go to this file, come down here, and
Source Code Control, and say View History,
| | 07:46 | we can actually completely
revert back to this one if we want to.
| | 07:49 | We can say Get This Version
or Rollback Entire Changeset.
| | 07:54 | So Get This Version will allow us, for example,
to say, all right, now I want to have that
| | 07:58 | version which still had My Novel in it.
| | 08:00 | Remember, you haven't lost anything. We can
come back up here and say Get This Version,
| | 08:06 | and now we're back to Website.
| | 08:08 | So that's the basic workflow when working
with files in TFS. You simply edit the files,
| | 08:13 | Visual Studio automatically checks things
out, you Check In using the Pending Changes
| | 08:18 | window, and you use the History window to
be able to do differencing and to be able
| | 08:22 | to revert to other Changesets.
| | 08:25 | Now let's move on and take a look at labeling in TFS,
and then after that, we'll look at branching and merging.
| | 08:32 |
| | Collapse this transcript |
| Tracking history and tagging| 00:00 | Tagging in TFS is called
creating labels, and it's really easy.
| | 00:04 | You do it from the Source Code Control Explorer.
| | 00:06 | Remember, tagging is the process of identifying
a particular set of changes in your repository
| | 00:13 | with a label so that you can come back later
and check that out, such as when you shipped
| | 00:17 | Version 1, and you start working on Version 2,
if you need to roll back to the Version 1
| | 00:22 | changes so that you can make
a bug fix and then come back.
| | 00:26 | So we'll go to this TFSSample--
that's the name of our project folder--
| | 00:30 | we'll go down to Advanced and say Apply Label.
| | 00:34 | And so for our Label, we're going to say v1 and
for our Comment we're going to say This is version 1.
| | 00:40 | Now, you can apply this
label to anywhere you want.
| | 00:43 | You can say the Latest Version, the version
that's in your Workspace, a particular Changeset
| | 00:48 | or a Date or even to another Label.
| | 00:50 | In this case, we're going to just
pick Latest Version and click Create.
| | 00:53 | And now we see that everything is all set,
it is Label v1 that's been created, and here
| | 01:00 | you see a log of all the other things that we
did before, replacing the file with different
| | 01:05 | versions and creating the label.
| | 01:07 | So once again, now if we come here and say
View History, you can see that not only is
| | 01:12 | there is a Changesets tab, there is a
Labels tab, and this allows you to keep track of
| | 01:17 | the labels separately from the Changesets.
| | 01:19 | So now I can do something like
come here and say Get This Version.
| | 01:24 | Now, in this case, it says all files are
up to date, we didn't actually do anything.
| | 01:29 | But if we had gone back to f1.cs and started
to make another change and say we said Node
| | 01:36 | not found and we saved
it and we checked it in,
| | 01:46 | now if we come back to our History and go
to the Labels, we can right-click here and
| | 01:49 | say Get This Version.
We come back to look at f1.cs, it's got Website.
| | 01:55 | But if we come back to the Changesets and
Refresh this, and come back and say Get This
| | 02:02 | Version, we can now see that it's back to Node.
| | 02:05 | And that's basically all it is to use labels
in TFS, it's all integrated into Visual Studio,
| | 02:11 | and it's all done by using this
Labels tab inside the History window.
| | 02:16 |
| | Collapse this transcript |
| Branching and merging| 00:00 | The last major piece of functionality we
need to explore in TFS is branching and merging.
| | 00:05 | Now, branching and merging are done quite
a bit differently in TFS than they are, say
| | 00:10 | in Git or Mercurial.
| | 00:12 | It actually creates new
folders inside your project folder.
| | 00:15 | So we'll come over here to our Sample and say
right-click, create a Branch, and we'll call it branch1.
| | 00:23 | Now, you can see that there are actually two
separate physical sets of folders inside this and this.
| | 00:32 | You see it's created over here in the
Folders section a new branch, and there's a little
| | 00:37 | T symbol there that
indicates that's a new branch.
| | 00:40 | Like some of the other systems, the branch
has been created, but it's not physically
| | 00:43 | in the repository yet until we check it in.
| | 00:46 | So we'll come over here to the Team Explorer, and
we'll add a Comment, Create Branch1, and we'll check it in.
| | 00:58 | So now we have our branch created, and you
can see that the branch is actually stored
| | 01:03 | in a completely separate folder, the
branch is stored in our project folder under the
| | 01:07 | folder TFSSample-branch1, whereas our original
project is stored over here under FSVC1\ConsoleApplication1.
| | 01:17 | So in order to switch to the branch, we
actually need to open up the appropriate Visual Studio
| | 01:21 | solution for the files.
| | 01:23 | So, for example, we'll come back to ConsoleApplication1,
underneath branch1, and double-click on ConsoleApplication1.csproj.
| | 01:32 | So now it looks like we're in the same place,
except if we hover on top of the file name, you'll
| | 01:37 | see that the full file name here says TFS1\
TFSSample-branch1\ ConsoleApplication1\f1.cs.
| | 01:45 | So if we make a change here, instead of
Node not found, we say Dwarf not found, and we
| | 01:51 | save it, and we can check
that in, Change node to Dwarf.
| | 02:00 | If we now come back to our Source Code
Explorer and ask to View History, you see that we have
| | 02:08 | a completely separate set
of Changesets for the branch.
| | 02:11 | Now, this is different again than the
version Git and Mercurial in that there is a set of
| | 02:17 | Changesets for each branch
that are completely independent.
| | 02:21 | So now if we want to switch back to our other
branch, to the main branch, we can come here
| | 02:25 | to ConsoleApplication1 and once again open
up ConsoleApplication1.csproj, and you can
| | 02:31 | see, not only we are back to Node, but if we hover
here, you can see we're back in the FSVC1 directory.
| | 02:37 | So now let's do something in the branch so
that we can actually have something to merge.
| | 02:41 | We'll go back to our Source Code Control
Explorer, go back to our ConsoleApplication1 in the
| | 02:45 | branch, open up the project again.
| | 02:48 | Now, we're not only going to change node to
Dwarf, we're going to add another function,
| | 02:56 | and then we're going to check this in, save
it, check it in, and once again if we look
| | 03:06 | at the History of our branch,
you can see we have our Add func2.
| | 03:13 | Now let's go back to the Source Code Control
Explorer, let's go back to this original main
| | 03:18 | branch, open up that project.
| | 03:20 | Then we are going to come back to the Source
Code Control Explorer, and we're going to merge.
| | 03:24 | So we right-click on the name of the folder,
come to Branching and Merging and select Merge.
| | 03:31 | Now it's going to ask us what we want to merge
with, and it's really clear here that it allows
| | 03:37 | you to decide which way you want to go.
| | 03:38 | Now, in on our case, this
merging is wrong direction.
| | 03:42 | This says right here the way it's configured now,
that would be merging our main branch into branch1.
| | 03:48 | We want to go the other direction.
| | 03:49 | So we'll use Browse and select branch1 as
the Source, and you can see it automatically
| | 03:56 | updated the target branch, because TFS is
smart enough to know you only have two branches.
| | 04:00 | If that weren't the case, we can come
here and Browse and select the main branch.
| | 04:05 | Now we'll click Next, and it asks us
which type of merging do we want to do?
| | 04:10 | Do we want to do it to the Latest Version or
to a particular Changeset or Label or Date?
| | 04:14 | In this case, we'll use the Latest Version.
| | 04:17 | It says all necessary information has been
collected, and it's getting ready to merge.
| | 04:20 | We click Finish button, and the merge is done.
| | 04:24 | Now it tells us that our file has been
modified outside the Editor, because the Editor had
| | 04:30 | the version that was in the main branch, and
when we did the update, it actually updated
| | 04:35 | the file in our Working Set directory on disk,
but hasn't actually updated the Editor, so
| | 04:40 | we're going to say Yes, we want it to reload.
| | 04:42 | And now when we come back to f1.cs, you can
see, not only do we have Dwarf, because that
| | 04:47 | was the change we made in the branch, we also
have our function 2, so we've successfully
| | 04:52 | merged back from our branch back to the main.
| | 04:55 | And if you recall our conceptual overview,
this is called a reverse integration, we actually
| | 05:00 | took what was in the branch and
brought it back into the main.
| | 05:04 | Now, if you're going to continue keep
working in the branch over a long period of time,
| | 05:08 | you'll want to make sure that you do a forward
integration by doing that merge in the opposite
| | 05:12 | direction from the main branch back to
your private branch on a fairly regular basis,
| | 05:18 | for example, weekly, to make sure that
your private branch doesn't get too far out of
| | 05:22 | date with changes that other
people are making to the main branch.
| | 05:26 | That's actually it for TFS.
| | 05:28 | Since we've used TFS only with the GUI, there
isn't any movie for using GUI and shell integration,
| | 05:35 | because TFS integration is all
done completely inside Visual Studio.
| | 05:38 | I hope you've liked the overview of TFS.
| | 05:42 | Obviously, Microsoft has tons of additional
documentation videos on Channel 9, lots of
| | 05:48 | information on being able to understand how
to more effectively use Team Foundation Server.
| | 05:55 |
| | Collapse this transcript |
|
|
7. GitInstallation and setup| 00:00 | Okay, let's roll up our sleeves and do
a little Source Code Control with Git.
| | 00:03 | Git is a distributed Source Code Control system.
| | 00:07 | That means that you host the entire repository
on your development box and other people host
| | 00:12 | the same complete repository on their development
boxes, and you can exchange files back and forth.
| | 00:19 | It also means that you can use things like
GitHub, which is a cloud-based service to
| | 00:24 | host repositories in the cloud in order to
save your work off of your development system,
| | 00:29 | if you're working by yourself. Git is free.
You can get the bits from git-scm.com.
| | 00:35 | And you can use GitHub if your product
is open-source to have free-hosting.
| | 00:40 | If your project is not open-source, you
can have private repositories on GitHub for a
| | 00:45 | very reasonable price. That's what I use
on a regular basis, also at github.com.
| | 00:50 | And they also have their own custom GUI
application for both Windows and Mac that allow you to
| | 00:57 | easily manage your local repositories and
syncing to your repositories on GitHub and
| | 01:03 | keeping the two of them
connected together. All right.
| | 01:06 | So let's dive in and install Git.
| | 01:09 | Okay, let's roll up our sleeves and
do some Source Code Control using Git.
| | 01:15 | The link for the Installation Binary is in the
Links.rtf file in the exercise files directory.
| | 01:21 | We're using the Git Installer from the git-scm.com
website, which is the main home of Git, and
| | 01:27 | it's a very forward MSI.
| | 01:29 | This is the very latest one as of the
time that we're recording this course.
| | 01:33 | And we can put it wherever we want.
| | 01:36 | And we're going to choose Run Git from the
Windows Command Prompt, because it works best
| | 01:42 | with our recording setup here.
| | 01:44 | If you're a Mac person or a UNIX person
working on Windows, you probably want to Use Git Bash
| | 01:50 | only, and then you have a
very familiar command shell.
| | 01:52 | In this case, we're just going to click Next.
| | 01:55 | And in our case, because again we're using
Windows, we're going to use Checkout Windows-style
| | 01:59 | and commit Unix-style line endings.
| | 02:02 | That allows us to use this repository
easily with Macintosh users and Linux users.
| | 02:07 | If you're going to use Windows only, then
you can click this Checkout as-is commit as-is.
| | 02:12 | All this affects is what is stored in the
repository, not what is in your working set.
| | 02:18 | So when in your working set you always
have carriage return line feeds, it just strips
| | 02:22 | out the carriage returns when it checks in and
reinserts them when it checks out for textual files.
| | 02:29 | Unzip a bunch of Git stuff, we're all set,
we don't need to look at the ReleaseNotes,
| | 02:34 | and the way we can find out if we've actually
got Git installed, first of all, you can see
| | 02:38 | the icon here for the Git Bash
shell, if we wanted to use it.
| | 02:42 | And we'll open up our Command window and say
git --version, and you'll see something like this.
| | 02:47 | Now, your version maybe different, but if
you get a message at all like that as opposed
| | 02:52 | to command not found, you know you've
got Git successfully installed. All right.
| | 02:56 | Let's move on to creating your repository
and doing some checking in and checking out.
| | 03:01 |
| | Collapse this transcript |
| Creating a repository and a project| 00:00 | All right, let's create a Git repository.
| | 00:03 | Git repositories, unlike TFS and Subversion,
actually live in the directory with your files.
| | 00:08 | There is no separate repository directory.
| | 00:11 | All right, so let's create a
directory to store our Source Code files.
| | 00:14 | We'll create mkdir g1, then we'll put
CD into there, and we'll say git init.
| | 00:21 | That initializes that empty repository.
| | 00:25 | We can validate it by saying git status,
and it says nothing to commit, and that's all
| | 00:30 | there is to creating a Git repository.
| | 00:32 | If we do git dir/a, you can see that there
is a hidden directory here called .git, where
| | 00:38 | all of the metadata is stored.
| | 00:40 | What's important is that if you want to
backup a Git repository with all the history, you
| | 00:44 | backup the entire directory here with all your
Source Code files, including this .git folder.
| | 00:49 | So depending on the compression tool you're
using, make sure that after you've made the
| | 00:54 | ZipBackup or the 7zbackup that, that
folder is actually in your archive.
| | 00:59 | And that's it, that's all there
is to creating a Git repository.
| | 01:02 | Let's move on to creating some files
and doing some check-ins and check-outs.
| | 01:07 |
| | Collapse this transcript |
| Working with check-in, checkout, and revert| 00:00 | Okay, we've got a Git repository
inside of our directory g1 here.
| | 00:05 | Before we start adding things, let's set
two git configuration items which will help us
| | 00:10 | make sure that all of our changes
are marked with our name and our email.
| | 00:15 | So we say git config user.name
and git config user.email.
| | 00:29 | No, that's not my actual email.
And now we can put in some code.
| | 00:33 | The content we're going to use is from
the new project's haiku error message page.
| | 00:38 | We're going to pick one that's happened to all
of us before we started using Version Control.
| | 00:42 | I'm going to create f1.c and main print f. With
searching comes loss, and the presence of absence.
| | 01:02 | "\My Novel\" not found.\n".
| | 01:14 | Now of course, this isn't going to ever happen
to you again now that you started to use Version
| | 01:17 | Control, but you know how that feels.
So we'll save the file, and we'll exit.
| | 01:22 | Now we'll add that to the
repository in two steps.
| | 01:25 | First, we have to tell Git to start
tracking that file by saying git add f1.c, and we
| | 01:30 | ask Git the status of our working set. It says
there is a new file ready to be checked in.
| | 01:36 | So now we'll add it to the repository, git
commit, and you can see it created one file.
| | 01:47 | If we ask Git for the status, it
says there is nothing new to commit.
| | 01:51 | And if we ask Git for the log, you can see
we have a message here that says there is
| | 01:56 | our Initial check in commit message and three
additional lines of information which we're
| | 02:01 | going to look at here.
| | 02:02 | The first line is the commit ID,
or essentially changeset identifier.
| | 02:08 | That's a 40-digit-long hexadecimal number,
which is a GUID, or a Global Unique Identifier.
| | 02:15 | Now, for most usage inside Git, you'll only
need to type the first four or five characters
| | 02:19 | of that GUID, so don't get scared by the
fact that it's going to be starting to ask you
| | 02:23 | to type in 40 digit numbers.
| | 02:26 | But you have to type in at least as much of
that in order to be able to uniquely identify
| | 02:30 | a changeset as necessary.
| | 02:32 | So especially on your own
system, it's probably four digits.
| | 02:34 | When you start working with more people,
it's probably five or six at the most.
| | 02:38 | So now let's make a change so we
can see Git's versioning in action.
| | 02:41 | We'll once again open up f1.c, and we're going
to change My Novel to Website, maybe a more
| | 02:53 | appropriate message for the internet age.
| | 02:55 | And now we're going to check it in again,
but this time we're going to use an editor
| | 02:59 | feature that's built into Git in
order to do our commit message.
| | 03:03 | So we're going to say git commit -a, and
Git opens up in this case, Vim, a editor that
| | 03:11 | allows you to put in your commit message.
| | 03:12 | So we're going to say Changed my novel to
website, and since this is Vim, it understands
| | 03:19 | all those wonderful VI commands that you
might know and love. In this case, what I do is I
| | 03:24 | hit the Escape key and then I type :wq to
Save it and Quit, and now it does the commit.
| | 03:31 | And if we do git log, you can see now we
have two changes, both our Initial check in and
| | 03:38 | Changed my novel to website.
| | 03:40 | If you just want to see the changeset IDs and the
comments, you can say git log --one line --all,
| | 03:49 | and now we have--you can see the first
seven digits of each one of those changeset
| | 03:54 | IDs and the commit message.
| | 03:57 | So now let's make another change and then
look at it and decide if we want to roll it back.
| | 04:00 | So once again, we're going to open up f1.c,
and we're going to change Website to Webpage,
| | 04:07 | and we're going to Save the file.
| | 04:09 | Now, if we want to see the difference between
our working set and what's in the repository,
| | 04:14 | we can say git diff, and you can see it shows
the one line has changed from website to web page.
| | 04:21 | Now, this show the difference with all files
that are currently changed in the working set.
| | 04:26 | If you want to see changes just for a single file,
you can say git diff and just put in the file name.
| | 04:31 | Now, in our case it's going to be exactly
the same, but if you had 25 files, that might
| | 04:35 | generate quite a bit of output.
| | 04:38 | You can also ask for the differences
between the working set and a specific changeset.
| | 04:42 | So if we do git log, we can see we've got our
two change sets. Let's ask for the difference
| | 04:48 | between our working set and not the most
recent one where we changed My Novel to Website,
| | 04:53 | but the initial one where initially we
checked it in and where we had My Novel.
| | 04:56 | So we'll say git diff, and we're going to
put in 87b53, and we'll see what happens.
| | 05:06 | So now you can see the difference between
that commit which we called our Initial check in
| | 05:10 | and the current state of our working set.
| | 05:12 | You can see our current working set in green here
says Webpage and the Initial check in said My Novel.
| | 05:18 | Now, your changeset IDs are
going to be different than these.
| | 05:21 | You'll need to run git log on your system
and type in the first five digits of the actual
| | 05:26 | IDs on your system, because GUIDs are partially
generated by the Mac address for your Ethernet
| | 05:33 | adapter in your computer and so it will be clearly
different than the system on which we're recording this.
| | 05:38 | So now let's roll back
to our most recent commit.
| | 05:41 | So we'll say git checkout HEAD f1.c.
| | 05:47 | If we type f1.c, you can
see we're back to Website.
| | 05:52 | You can also revert to any particular revision, not
just the topmost one, by using the checkout command.
| | 05:57 | So we'll say git log, and now we're going
to revert back to the initial one, so we're
| | 06:04 | going say git checkout 87b53 f1.c, and now if we
type f1.c, you can see we're back to My Novel.
| | 06:16 | Note, none of the changes in your repository
have been lost. You're just updating the working
| | 06:20 | set to the one that you want.
| | 06:21 | So for example, we can go back to git
checkout HEAD f1.c, and we're back to Website.
| | 06:30 | All right, that's the basic working flow of
checking in, checking out, and reverting with Git.
| | 06:37 | Let's move on to tagging and labeling with Git.
| | 06:42 |
| | Collapse this transcript |
| Tagging| 00:00 | Tagging in Git is really easy.
Tags are called tags.
| | 00:04 | To create a tag, we'll say git tag, add the tag,
v1, and then we'll add a message to indicate
| | 00:10 | what it is we want, like Label version 1.
| | 00:16 | Now to see the tags in your repository,
it's as simple as saying git tag.
| | 00:20 | To see what's in a specific tag, you can
just type git show and the tag, and here we can
| | 00:25 | see that the tag is shown, and it specifically
shows up here at the top that I made the tag
| | 00:30 | and when I did and exactly what is in there
and what the various differences are between
| | 00:35 | that tag and what's in my working set.
| | 00:37 | Now, if I want to go back to that tag at a
later date, for example, in order to fix the
| | 00:41 | bug, I can say, git checkout v1, and if I want to
get back to the HEAD, I can say git checkout HEAD.
| | 00:52 | Because branching is very easy in Git, you
want to do a checkout to your tag and then
| | 00:56 | do a branch there to allow you to make sure
your changes are independent of whatever changes
| | 01:02 | you were actually doing at the HEAD.
| | 01:04 | So for example, if you had to come back to
version 1 three months from now, you'll do
| | 01:08 | a checkout v1, you'll branch at that point,
make your changes there, and you may merge
| | 01:13 | them back into the main branch, or you may keep
that separate as your version 1 branch from now on.
| | 01:19 | One last thing. If you want your tags to be
copied to a remote repository, you have to
| | 01:23 | use the command git push --tags, like this,
and if you want to pull them from a remote
| | 01:31 | repository you use git pull --tags, with
the appropriate additional arguments here that
| | 01:36 | indicate which repository
you're pulling from or pushing from.
| | 01:40 | So tags are not by default
automatically copied on a push or pull.
| | 01:45 | All right, that's tags in Git. It's really,
really simple. It allows you to just back up
| | 01:50 | to wherever you were at that
particular point and carry on.
| | 01:53 | Again, I highly recommend if you're going
to use tags, when you do a git checkout at
| | 01:58 | a particular tag, do a branch at that point.
As you'll see in the next movie, branching
| | 02:02 | is really easy so that you make sure that
you carry on with your version 1 independently
| | 02:07 | of the changes you might have already made
up to that point, say when you're working
| | 02:10 | on version 1.1 or version 2.
| | 02:15 |
| | Collapse this transcript |
| Branching and merging| 00:00 | The last major piece of functionality we
need to explore is branching and merging.
| | 00:05 | In Git, branching and merging is
very easy and very lightweight.
| | 00:09 | So first, let's run Git branch. We
can see we are on the master branch.
| | 00:14 | This is sometimes called the trunk.
| | 00:17 | To create a branch is as easy as saying git
branch b1, and now we have a new branch, you
| | 00:24 | can see we have branches b1 and master.
| | 00:27 | And you can see between the asterisk and the
text in green, they we're on the master branch.
| | 00:32 | So in order to make changes in the branch
and work with that, we need to check that branch
| | 00:36 | out and then we can make updates.
| | 00:38 | So git checkout b1, I can see it says we
switch to branch b1. If we do git branch, you
| | 00:46 | can see we are on branch b1, so now we'll go and
update our file and add a new feature. One more haiku.
| | 00:54 | "No available space," "Look to the cloud,"
"Your drive is full".
| | 01:05 | I will save that, we will exit, and
then we'll commit that in the branch.
| | 01:13 | Now if we say git log, you can see that we
have the Update in branch, and you can see
| | 01:20 | we have changed my novel to website,
and we can see we have Initial check in.
| | 01:24 | But there is nothing there that makes it clear
that the update was done in the branch because
| | 01:28 | the set of revisions is global
between all the various different branches.
| | 01:33 | So let's make another change, and we'll go
specifically and make the commit message to
| | 01:36 | show what is what we want to do.
| | 01:38 | So we'll say Notepad f1.c, and we'll come
down here and change the word Website to Node,
| | 01:47 | and save that, and we'll quit and then we'll do
another commit, and we'll say b1 Change website to node.
| | 02:00 | And there's a convention that's just handy to
know which branch you are making the changes in.
| | 02:04 | So now if we say git log, you can see it's very
clear that that change was made in branch number one.
| | 02:10 | All right. Now let's talk about merging.
| | 02:14 | If you continue to work in a branch for an
extended period of time, you'll want to do
| | 02:18 | a merge from your main branch back into your private
branch. Remember, that's called a forward integration.
| | 02:24 | Time to do this varies depending
upon how active the main branch is.
| | 02:28 | So usually I do that weekly if I am
working in a project with somebody so that I make
| | 02:33 | sure that my private branch is up to date in
all the places where I am not currently working.
| | 02:38 | Now in our case, we are simply going to do a reverse
integration from our branch b1 back into the master.
| | 02:45 | So the way you do this is you first switch
back to the master, and if we type f1.c,
| | 02:51 | you can see we don't have our new
feature, and it still says website.
| | 02:55 | Now we are going to merge, git merge b1, and
now if we type out f1.c, you can see it not
| | 03:02 | only has the word Node, it also
has our second function, feature1.
| | 03:06 | You'll see one thing up at the top there where
we did the git merge b1, it says Fast-forward,
| | 03:12 | and that means that Git recognizes that b1
came off of a common starting point with our
| | 03:19 | master branch, so therefore, it was able to
replay the changes very, very quickly by knowing
| | 03:24 | that it didn't have to like start looking at
everything because it knew where they both began to differ.
| | 03:30 | Well, that's it for
branching and merging in Git.
| | 03:33 | Next up, we'll take a look at some shell
integration and some GUI tools for Git that were installed
| | 03:38 | when we installed the Git
installation that we got from git-scm.com.
| | 03:43 |
| | Collapse this transcript |
| Working with GUI clients and IDE integration| 00:00 | The latest version of Git that you can get
from git-scm.com has built-in GUI tools and
| | 00:08 | shell integration. As you can see here, we've got
something we can create, Git and add all new files.
| | 00:14 | There is a specific Git Commit tool, a Git
History tool, we can fire the whole thing
| | 00:19 | up by calling up for the Git GUI, and it
knows which repository you can see up here in the
| | 00:25 | title bar, it's using because we
right-clicked on that particular folder.
| | 00:30 | So you can see there aren't any
Unstage Changes or Stage Changes in here.
| | 00:34 | We come up to Repository and say Visualize
master's History, and there's our changes.
| | 00:40 | That's our Initial check in. You can see down here at
the bottom, there is our initial text. We go up one.
| | 00:46 | Now you can see it shows the dif where
we took out my novel and put in website.
| | 00:50 | Here's what we added, the feature code to
our branch, and up here is where we added node.
| | 00:58 | And you can see by the fact that it now has this b1
and master at the same spot on the top line there,
| | 01:03 | those two branches have been merged together.
| | 01:06 | In addition to doing that, you can browse
master's Files, or you can browse files in
| | 01:11 | various different branches if you've
been asked for Database Statistics.
| | 01:14 | For example, here we can see these are
statistics that have to do with the way in which Git
| | 01:20 | manages things, and it basically
never deletes anything.
| | 01:23 | So over time, you start using
this, for 6 months or a year,
| | 01:28 | you may end up with a lot of extra files
that are no longer being tracked by Git that are
| | 01:32 | still in that hidden.git directory.
| | 01:35 | You can use this tool to commit it and
compress that and get rid of the unnecessary files
| | 01:39 | that you are still carrying around if
you're backing up the entire directory.
| | 01:42 | And that's it for Git GUI
and Git shell integration.
| | 01:45 | I think you'll find that Git is very, very
easy to use, very lightweight, and something
| | 01:50 | that I highly recommend. It's also being used
very, very widely in the open-source community,
| | 01:56 | especially with a website called github, g-i-t-h-u-b.com,
which has free hosting for open-source projects,
| | 02:04 | and I also highly recommend github for
hosting private repositories for a very reasonable
| | 02:09 | price that allows you to then push the
changes from your local repository to the cloud.
| | 02:14 | And if you remember my story from the
beginning of the course, I was talking about restoring
| | 02:17 | my hard disk, it was on github where my files
were located in the cloud, and it was very easy.
| | 02:23 | All I did was went to github and did a
pull down form the github cloud version, and my
| | 02:27 | local repository was completely restored.
| | 02:30 | And finally, as we did with Subversion, we're
going to zip the entire finished copy of the
| | 02:35 | Git repository here we have in directory
g1 and put it in the exercise files for this chapter.
| | 02:40 |
| | Collapse this transcript |
|
|
8. MercurialInstallation and setup| 00:00 | Let's do some source
code control with Mercurial.
| | 00:03 | Mercurial is a distributed control system similar to Git,
which means that the repository is hosted on your box.
| | 00:11 | You can also host repositories on another developer's
box and they host the same complete repository,
| | 00:17 | and you exchange information either with
pull and push or with import and export.
| | 00:22 | And then you can also have server-based
connections to Mercurial repositories which allow you
| | 00:27 | to use pull and push to repositories
in the cloud for shared repository use.
| | 00:32 | It's free, and there are
also commercial hosting options.
| | 00:35 | You can get the free version, as it says, here on
the screen, at mercurial.selenic.com/wiki/Mercurial,
| | 00:42 | and there's also commercial
hosting from a company called atlassian.
| | 00:46 | We're going to install a local version of
Mercurial which is abbreviated Hg, as in the
| | 00:50 | elemental symbol for Mercury.
| | 00:52 | Because Mercurial is such a tongue twister,
I'm going to call it Hg throughout the remainder
| | 00:57 | of movies in this chapter.
| | 00:59 | The link for the installation binary is in the
Links.rtf file in the Exercise Files directory.
| | 01:06 | Let's go ahead and fire up the setup here,
and we'll go through the setup wizard, we
| | 01:10 | do accept the license terms, then we're
going to install the complete package and accept
| | 01:14 | the location for the default directory.
Now we're going to click install.
| | 01:18 | All right, and that's it. Now
we've got Mercurial installed.
| | 01:22 | Now let's fire up a command line and
make sure our installation is correct.
| | 01:27 | Just like with Git, we can just do hg-version,
and so we go we've got been Mercurial Distributed
| | 01:33 | SCM (version 2.3.2), your version maybe newer
depending on how long after we've got finished
| | 01:40 | recording this course that you
downloaded your installation Mercurial.
| | 01:43 | We're all set. We've got it installed.
Let's go make a repository and some projects.
| | 01:48 |
| | Collapse this transcript |
| Creating a repository and a project| 00:00 | Hg repositories live in the
same directory with the files.
| | 00:05 | Unlike Subversion, Perforce, and TFS,
there is no separate repository directory.
| | 00:10 | Like Git, this makes it possible for you to
backup the entire directory, say, with zip
| | 00:15 | and not only back up your files, but also back up
all the version control metadata in a single place.
| | 00:21 | So first, let's create the directory. I'll call it
hg1, then we'll CD to hg1, and we'll do hg init.
| | 00:30 | Like Git, Hg stores all of its metadata
in a hidden directory here called .hg.
| | 00:37 | If we run hg status, unlike Git, we don't see any
message because there's nothing going in our repository.
| | 00:44 | If you haven't properly initialized the repository
and you ran hg status, you we'll get an error
| | 00:49 | message telling you that
no repository was found.
| | 00:52 | Since we got just a blank
response, we know we're all good to go.
| | 00:56 | Let's move on to creating some
files and checking in and checking out.
| | 01:01 |
| | Collapse this transcript |
| Working with check-in, checkout, revert, and tracking history| 00:01 | All right, we've got a working HG repository.
It's time to add some files and check it in.
| | 00:07 | Mercurial is different than some of the
other systems because we have to do one piece of
| | 00:10 | initialization globally before
we can start checking things in.
| | 00:13 | What we have to do is to create a file in
the user profile called Mercurial.ini, and
| | 00:20 | inside of it we had to put in
our username and email address.
| | 00:23 | So we'll say Notepad, %userprofile%\Mercurial.ini.
It doesn't exist, we do want to create it.
| | 00:33 | I copied the text that we need onto the clipboard,
so you will type in ui, then username = and
| | 00:38 | here you will put in your username, and
over here you'll put your email address.
| | 00:46 | Just remember, this is not a real email
address. Don't try sending email there.
| | 00:51 | Okay, now we have got
Mercurial fully initialized.
| | 00:54 | We can start putting in some code.
So let's open up Notepad and create our file.
| | 01:00 | The code we are going to put in has some content
from the new project's haiku error messages page.
| | 01:04 | We'll pick one that's happen to all of us
before we start using Version Control "With
| | 01:08 | searching comes loss\n", "and the presence of
absence:/n", and then the kicker "My Novel\" not found.\n".
| | 01:25 | Well, at least this one will never happen
to you again, now that you are going
| | 01:28 | to be a Version Control expert.
All right. We'll save it.
| | 01:33 | Now if we do hg status, you can see that HG
sees it but doesn't know what to do with the file.
| | 01:39 | So we need to tell it that this is a
new file for the repository, hg add f1.c.
| | 01:45 | Okay, now we can ask Hg the status again
and see that it's got the file ready to add.
| | 01:52 | So finally, remembering that we set up our
Mercurial.ini file at the top here, we'll
| | 01:56 | check it in, and everything would be fine,
hg commit -m "Initial Checkin". All right.
| | 02:04 | Now if we ask Hg status again, you will see
there is nothing going on, and then we see hg log,
| | 02:10 | and you can see that it puts
out five lines for each changeset.
| | 02:14 | If you look at the first line, you
can see the changeset identifier.
| | 02:18 | Now in Mercurial there is two numbers, one--
0 in this case--is the local identifier that
| | 02:24 | you can use for doing things like reverting and
versions. We'll see that later on in this movie.
| | 02:29 | The second is a hash that's used to
uniquely identify this changeset so that when this
| | 02:36 | changeset is for example exported or
pushed to a remote repository, they can make sure
| | 02:41 | that they can uniquely identify that from other
changeset zeroes that might come in from other users.
| | 02:47 | You can see our user as we set it up in
the Mercurial.ini file, the date, the summary
| | 02:52 | and so forth where you see tag: tip--that's
the same as Git Head--and it essentially says
| | 02:58 | this changeset was added to the
most recent version of repository.
| | 03:02 | So this is the top or the tip of the iceberg here
that has everything in it, that's the very latest stuff.
| | 03:07 | So, now let's make another change so
we can see Hg's versioning in action.
| | 03:14 | We'll open up our file, and we'll change
My Novel to Website and then we'll save it.
| | 03:23 | This time we are going to do hg commit, but
we are not going to put a message audit on
| | 03:28 | the command line here, we are going to let it open
up Notepad so that we can put in a multi-line message.
| | 03:34 | So we'll say Change My Novel to Website, This is
a better change for modern times. We'll save it.
| | 03:48 | Now if say hg log, you will see
that you only see the summary.
| | 03:53 | If you want to see the full commit
messages, you have to say hg log -v.
| | 03:58 | And there you can see in our changeset,
number 1 there. It's--instead of saying summary, it
| | 04:03 | now says description. All right.
| | 04:05 | So now let's make another change and
then examine how to revert or rollback.
| | 04:09 | Once again, we'll open up f1.c, and we'll
change Website to Webpage, and we'll save it.
| | 04:19 | If we run hg diff, you can see that if we
committed this change. It would change Website
| | 04:26 | to Webpage, and you can see it shows you
the difference between what's in your working
| | 04:31 | set and what's in the repository.
| | 04:34 | Note in our case, we only have one file.
If you had 25 files, when you said hg diff,
| | 04:39 | it would show the
difference in all of the files.
| | 04:41 | You can ask it to show you the differences
in only a single file by typing hg diff f1.c.
| | 04:46 | Now in our case, that's exactly the same
since we only have one file, but you understand
| | 04:51 | now how to see the
difference for an individual file.
| | 04:54 | There is a lot of additional options on the
diff command so that you can ask it to show
| | 04:57 | you the difference between different times, and
you can also ask it to show you the difference
| | 05:02 | between the working set
and a specific changeset.
| | 05:05 | If we do hg log, we can see that
we have changeset 1 and changeset 0.
| | 05:10 | So if we say hg diff -r 0, it will show us
the difference between our current working
| | 05:17 | set which has web page and the initial
Checkin which had My Novel. All right.
| | 05:23 | So now let's roll back to our most recent
commit, and we do that by saying hg revert
| | 05:28 | in our file name, we type out f1.c, and
you can see now we are back to website.
| | 05:34 | Finally, you can also revert to any revision,
not just the topmost one by using the revert
| | 05:38 | command and specifying a changeset so that
we'll do hg revert -r 0 f1.c, and again we
| | 05:47 | type out f1.c. You can
see we are back to My Novel.
| | 05:50 | Now, note none of your changes in the repository
have been lost, you are just updating the working set.
| | 05:55 | So if we just say hg revert f1.c,
you can see we are back to website.
| | 06:01 | So that's the basics of checking in
and checking out and reverting with Hg.
| | 06:06 | Now let's move on to talking about tagging.
| | 06:11 |
| | Collapse this transcript |
| Tagging| 00:00 | Creating tags in Hg is really easy.
First, let's see what tags are in the repository.
| | 00:05 | In our case, there's only the one marked
tip which represents as I said before the very
| | 00:12 | most recent changeset in the
main branch along the trunk.
| | 00:16 | Again, remember the numbers, you see on
the screen the changeset ID and the hash may
| | 00:21 | differ between this system and your system.
| | 00:24 | Create a tag it's very easy, hg
tag v1, and now we do hg tags.
| | 00:31 | Now we can see that we now have two tags
tip and v1 to check out the version marked by
| | 00:38 | a tag we use hg update.
| | 00:41 | But let's make a tag without tag v1 now.
Let's make a change to our mainline and check it
| | 00:46 | in so that we can switch back and forth between
the tag and the mainline we can see the difference.
| | 00:51 | So we'll come in here, and we'll change this
colon to an ellipses, we'll commit that,
| | 01:07 | and now we type f1.c. You can see we have
the ellipses there, but if we see hg update,
| | 01:15 | now we type f1.c, you can see it's back to
a colon, and if we type hg update, and
| | 01:27 | you can see it's back to the ellipses.
So that's how easy it is to do tags in Hg.
| | 01:32 | Just remember when you switch back to the tag,
you're essentially moving the update pointer backwards.
| | 01:37 | So you may want to create a branch if
you're going to be making changes when you switch
| | 01:41 | back to say version 1 in order to make an
update to version 1 of your source code.
| | 01:45 | But branching and merging is very easy in
Hg, and we'll see that in the next movie.
| | 01:50 |
| | Collapse this transcript |
| Branching and merging| 00:00 | Let's explore branching and merging in Hg.
In Hg, branching and merging is very easy.
| | 00:06 | First, let's run hg branch and see that there
is only one branch default, and that's the one
| | 00:11 | we're on. Sometimes it's called the trunk.
But in Hg, it's called the default.
| | 00:15 | So to create a branch, we say hg branch b1.
| | 00:19 | Now notice it says mark the
working directory as branch b1.
| | 00:22 | It hasn't actually done the branch yet,
so we have to commit it to make the branch.
| | 00:29 | Okay, now if we say hg branch, you can see
we're on branch b1, and if we see hg branches,
| | 00:38 | you can see there are two
branches, b1 and default.
| | 00:41 | Now to work with a branch we simply update
to the branch, hg update b1, and we ask hg
| | 00:49 | branch it tells we're on b1, and if we say
hg update default and we type hg branch,
| | 00:56 | we're back on the default branch.
So let's go back to branch b1 and make a change.
| | 01:03 | So we'll add another feature to our little
haiku up here "No more available space,"
| | 01:16 | "Look to the cloud," "Your hard drive is full!"
| | 01:29 | Now if we save this and commit it--and
remember now we can say hg branch--and see that we're
| | 01:38 | in branch b1, type out f1.c, and see that
we've got the new feature. If we go hg update default,
| | 01:45 | type out the f1.c, you see we
just have the original values.
| | 01:50 | I'll go back to the branch, I will look at
the log, and you can see that it shows us
| | 01:58 | in the list which branch it was in.
So it was in branch b1 that we did the update.
| | 02:03 | Like Git, however, it's a good convention in your
summary to indicate which branch the changes are in.
| | 02:10 | So now we're going to go make one other
update, and we're going to change website to node
| | 02:19 | and then we'll commit that, and we'll put
the branch number in front of it, so we know
| | 02:25 | exactly where we did, what we did.
| | 02:28 | All right, so now let's talk
a little bit about merging.
| | 02:32 | If you continue to work in a branch for an
extended period of time, you'll want to do
| | 02:36 | a forward integration from the
default back to your private branch.
| | 02:39 | Remember back in the conceptual section we talked
about forward integration and reverse integration?
| | 02:45 | Forward integration is that process of taking
things from the main or the trunk or the default
| | 02:49 | and moving them into your private branch.
| | 02:52 | The purpose of doing this is to make sure
that your private branch doesn't get too far
| | 02:55 | out of date with the main, if you have
other people working on the main branch
| | 03:00 | so that you're collecting together updates
perhaps in sections of the application that
| | 03:04 | are different than the one you are working in.
| | 03:07 | Now in this case, we don't have anything
useful in our main branch to bring forward, so we're
| | 03:11 | just going to do a reverse integration.
| | 03:13 | Remember, a reverse integration is taking changes from
our private branch and putting them back in the main.
| | 03:18 | In order to merge, we need to switch back
to the master branch or the default branch.
| | 03:23 | So we're going to say hg update default, we
can see we just have our original data, and
| | 03:29 | then we're going to ask it to merge
branch b1 get back into the default branch.
| | 03:35 | And notice it says here, again,
branch merge, don't forget to commit.
| | 03:39 | If we see hg status, you can see that not
only does it have modified file f1. It also has
| | 03:45 | this file it doesn't know what to do with
code f1.c.orig, and you should just leave
| | 03:51 | that alone, and in this case, we're going to
do the commit, and if we do hg log, you can
| | 04:01 | see that now we have our
updated from branch b1, and that's it.
| | 04:07 | Now we type f1.c, you can see we have all
our changes from the branch merged back into
| | 04:13 | the default, we can verify when the default
branch by saying hg branch and see that we're
| | 04:18 | in the default branch.
| | 04:20 | So that's branching and merging in Hg. Next
step, we'll take a quick look at looking at
| | 04:25 | GUI tools and shell integration for Hg.
| | 04:30 |
| | Collapse this transcript |
| Exploring GUI and shell integration| 00:00 | Okay, in order to get GUI support for
Hg, we use a free tool called TortoiseHg.
| | 00:06 | The link for downloading this you'll find in the
Links.rtf file in the Exercise Files directory.
| | 00:14 | Go through, we accept the license terms, we
want to have everything installed the complete
| | 00:18 | package, we'll leave the default installation
directory alone, and the setup here will take
| | 00:24 | just a second, and now we're all finished.
| | 00:29 | Now let's go back to our Explorer and look
at the files on here, and if we go into Hg
| | 00:37 | you right-click on Hg, you'll notice that it
sees that now that this is an Hg directory.
| | 00:42 | If we right-click on something else, you
don't see HG commit, but if you see HG Commit,
| | 00:48 | you know that that particular
directory has an HG repository in it.
| | 00:52 | So if we look at HG Workbench, this allows us to
see the full GUI that is supported by these tools.
| | 00:59 | You'll be able to see here a graphic
representation in that railroads diagram there on the left
| | 01:04 | of our branching and merging.
| | 01:07 | Some of the other things you can do with
this shell integration is you can go in here
| | 01:11 | into the directory, click on the file, and
say things like Revision History or Remove or
| | 01:18 | Forget files, Rename or Revert
all from inside your visual shell.
| | 01:22 | And that's it for Mercurial. We've created a
repository, we've added some files ,checked
| | 01:28 | in, checked out, reverted, we've done some
tagging, we've done some branching and merging,
| | 01:34 | and that will get you up and going on
distributed version control with Mercurial.
| | 01:39 |
| | Collapse this transcript |
|
|
ConclusionSelecting a software version control that is right for you| 00:00 | Well, we've made it this far. We've covered
the concepts of what is software version control.
| | 00:06 | We've talked about the concepts of checking
in and checking out, reverting, rolling back,
| | 00:12 | branching, merging, tagging, labeling, and
we've covered it in detail for five different
| | 00:18 | products: Subversion, Perforce, Microsoft's
Team Foundation Server, Git, and Mercurial.
| | 00:25 | With all this information, how do you make a
decision as to which one is right for you?
| | 00:30 | Well, there's two main considerations.
| | 00:33 | One, if you're working in a team, and you're
working in a company, or you have a client
| | 00:38 | who already has an existing centralized
version control server, you are pretty much going
| | 00:42 | to use what it is they ask you to use, and
that'll probably either be Subversion, Perforce, or TFS.
| | 00:49 | If you're starting up your own team, I
would highly recommend using Git or Mercurial.
| | 00:53 | Both Git and Mercurial each have different
followings and different key features.
| | 00:58 | That might be a decision for you.
For me, I most often use Git for two reasons.
| | 01:04 | One, there is integration for Git inside
Apple's Xcode Development Environment, and there's
| | 01:09 | also integration for Git available for Visual
Studio, and two, Git hub, which I mention during
| | 01:15 | the chapter on Git, is a hosted service,
which is free for open-source projects and very,
| | 01:21 | very low cost for private
repositories for commercial projects.
| | 01:26 | And it makes it very, very easy for you to
use the Git repository on your local device
| | 01:32 | and then push your changes periodically to
the server on the cloud to the Git hub server.
| | 01:36 | Now if you remember back to my original story
about restoring my hard disk, Git hub was the
| | 01:41 | service that I used when I was restoring
my drive, and it worked very well from me.
| | 01:46 | If you're working in an environment where
you're really working with the distributed
| | 01:49 | team, sometimes Git and Mercurial can be best
| | 01:52 | because you can export and import and send
the differences by email without having to
| | 01:57 | set up a server infrastructure
for all of your team members.
| | 02:00 | And remember Git is what's being used for the
Linux Kernel by a team of a few hundred developers.
| | 02:07 | After digging into all five of these products,
you'll probably have a feel for which one suits
| | 02:13 | your working style the best.
| | 02:15 | So if your organization doesn't mandate the use
of a particular version control software system,
| | 02:20 | pick the one that you feel works best for you.
| | 02:23 | If they all seem equal to you, I'd highly
recommend using Git. It's lightweight and
| | 02:27 | it's efficient and it does the job.
| | 02:30 |
| | Collapse this transcript |
| Next steps| 00:00 | Now that you've seen an
overview of Software Version Control,
| | 00:04 | what are your next steps?
Well, if you decided to use Git
| | 00:07 | I highly recommend watching the Git
Essential Training from the lynda.com online training
| | 00:12 | library here, done by Kevin Skoglund.
| | 00:15 | If you decided to use Subversion, you can get
everything you need to know about Subversion,
| | 00:18 | including a free book here
at subversion.apache.org.
| | 00:24 | If Perforce is what you want to use, or Perforce
is what you are required to use by your enterprise,
| | 00:28 | all the information you could
ever want is here at perforce.com.
| | 00:32 | Information about Microsoft's Team Foundation
Server, including the Team Foundation Server
| | 00:36 | express Edition 2012 is available
here at this address at microsoft.com.
| | 00:43 | The canonical download for Git
is available here at git-scm.com.
| | 00:48 | And finally, Mercurial's home
is here at material.selenic.com.
| | 00:54 | So that's an exploration of the
Fundamentals of Software Version Control.
| | 00:58 | Hopefully you'll find one that does just
exactly what it is you need to do, and you'll never
| | 01:02 | have to read one of those error message
haikus ever again. Happy versioning.
| | 01:08 |
| | Collapse this transcript |
|
|
