WWDC2013 Session 414

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Silence ]
[ Applause ]
>> Kevin Lindeman:
Good morning everyone.
Welcome to understanding
Source Control in Xcode.
My name's Kevin Lindeman, I'm
an Xcode Software Engineer.
So first off we have so
much new stuff in Xcode 5
that we want you to take a look
at our session from last year,
Source Control Management in
Xcode, to learn about some
of the more basic integration
of Source Control in Xcode.
It's all the same in Xcode 5.
And that session in conjunction
with this year's session will
give you the full picture of how
to use Source Control in Xcode.
So I'm going to start
off talking
about the three C's
in Source Control.
The first one is Confidence.
Using Source Control in Xcode
gives you the confidence
that you're committing
the right code.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It also gives you the confidence
that when you're
using branching,
you're committing
to the right branch.
Now using Source
Control also allows you
to commit your changes
in smaller chunks
so that you can go back in
history using the version editor
or blame and see exactly
why a change happened,
when it happened and by who
and maybe go back and run
that version of the code instead
to try to find regressions.
It also helps with
compartmentalization.
Xcode has excellent
branch management
so when you're working on a
potentially large feature,
you can branch off of your main
code and iterate on that branch
over time until you're ready
to make that your main branch
and merge all of that
code into your main line.
The third C is Collaboration.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now especially with our
integration with OS X server,
Source Control becomes
an easy two-way street
of pushing changes back and
forth to your coworkers so that
when you make a change you
can give those changes easily
to your coworkers so that you're
all always building the latest
stuff in your project.
So we've added a lot to
Source Control in Xcode 5.
And the first thing is we're now
shipping the latest Subversion
client, Subversion 1.7.
We also have a much
improved checkout workflow
that I think you'll really love.
We've also got brand new
workspace centric workflows
so there's no more running back
and forth between the workspace
and the repository organizer.
We also have deep integration
with the Xcode service
on OS X server making really
easy so that when you start off
with a new project, putting
that project under Git
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and automatically pushing that
project to your OS X server.
We also have greater
customization using a new Source
Control preference
pane allowing you
to make Source Control
work with you.
So let's talk about
Subversion 1.7.
One of the key differences
compared to Subversion 1.6
which we shipped in Xcode 4,
is that when you have a project
like you see here
every folder inside
of that project has
a .svn folder in it.
Now if you're looking at that
project in Terminal or something
that really clutters up
your folder structure.
Subversion 1.7 when you
upgrade to it, it takes all
of the .svn folders lower down
your file system and puts them
up into the top level .svn
folder for your project.
This makes it much more
similar to how a Git works.
Now the first time
you open a project
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in Xcode 5 you'll
see this dialogue.
It's asking you to upgrade
your project to Subversion 1.7.
Now this will be handled
entirely by Xcode,
you don't have to do anything.
It's also entirely client side.
It doesn't change
anything on your server.
And each individual
team member can opt
into upgrading to
Subversion 1.7.
Now this is an important
distinction
because Xcode 4 only
supports Subversion 1.6.
So when you're going back
and forth during the
developer previews of Xcode 5,
you'll need to be using
Subversion 1.6 if you want
to use Source Control
in Xcode 4.
But we really do urge you to try
to upgrade because there's a lot
of really great enhancements
in Xcode 5
when you use Subversion 1.7.
The first of those is
improved performance.
Operations such as SV
and up are a lot faster.
We've also added support for
blame for modified files.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I'm sure you've been working in
Xcode, modified a file, haven't
yet committed it yet
but then wondered,
well who changed this line
over there and noticed
that you couldn't look at
your locally modified version
of that file in blame.
Well now you can
with Subversion 1.7.
That also has always
worked with Git.
We also have this great new
feature called blame for line.
It's a shortcut in
the standard editor.
You don't even have to
go to the Version Editor
into the blame submode to see
blame for your whole file.
You can just say I'm curious
about what this line is,
right click it in Git and
a great popover a view
of who changed that line,
when it was changed, why,
with quick shortcuts for opening
it in the full blame editor
or into the comparison editor
so you can see all the
changes in that file.
It also highlights all of the
other lines in that source file
that were modified
with the same commit.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And also the command
line integration.
When you install the Xcode 5
version of command line tools,
all you will have access
to is Subversion 1.7.
Subversion 1.7 cannot talk to
a Subversion 1.6 working copy
until you upgrade and vice
versa, 1.6 cannot talk
to a 1.7 working copy.
But like I said, this
is entirely client side
so you don't have to upgrade all
of your working copies
right now.
So moving onto this new
workspace Source Control.
There's three things that
that takes into account.
First is the new
accounts preference pane.
Instead of setting up a
repository on the organizer,
you can go to the accounts
preference pane and set up any
of your accounts that would
have login credentials
that Xcode will talk to.
And there's also the
new Source Control menu.
We've taken a lot of the
new features of Xcode 5
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and all the old ones
and put them
into a top level menu for you.
We've also got the
new checkout workflow.
And so let's talk about
the accounts preferences.
As I said this is the
single place for doing all
of your credential management.
You can set up Apple
IDs for setting
up provisioning of your devices.
You can also set up
Subversion servers and any
of the credentials used
for those, Git remotes
and OS X server accounts so
that you can get the OS X server
integration in Xcode.
Now let's talk about
the Source Control menu.
This is great because we've
taken all the working copies
that are part of your workspace
and put them at the top
of the menu because
we know you want
to know what Source Control
working copies you're using
in your project.
We've also added the ability to
show the current branch for each
of those working
copies right there
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
so you know what you
are committing to
and what you're building.
Under each of those
working copies is our branch
management tools.
You can also do on demand
upgrades here if you opted not
to upgrade on workspace open.
Then there's some of more
top level items like checkout
for getting new Source Code,
commit, push, pull and update
and a new workspace wide
history view which will take all
of the working copies in your
project, show you the logs all
in one list that
is also searchable.
So now let's talk
about Checkout.
As I said brand new look, a
lot easier to use as well.
But it's also a lot
more powerful.
We show recent projects that you
have open or checked out as well
as recent repositories
that you have checked
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
out from right there.
We also have favorites.
You can now star a repository or
project and have it always show
up under the favorites tab.
There's also the repositories
tab which will take all
of the repositories you have set
up in the accounts preferences
and list them here as well as
any repository that is hosted
on your OS X server using
its Git integration.
It will also show you browsing
a subversion repository
when necessary.
Xcode 5's checkout is way smart
so it actually does subversion
branch auto discovery.
So if you type in the
URL the Xcode can figure
out what you might be checking
out, whether it's a branch
or it knows that there's a
bunch of branches in there,
it will just show you
that, you don't even need
to browse your repository.
But if you put in a URL
that's a little ambiguous
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
such as sometimes if you have
a multiple projects hosted
in a single repository and
you just give it the root URL
to your repository, we can't
really tell exactly what you
wanted to checkout just yet so
it will allow you to browse.
Let's take a quick look
at this in the demo.
So we have here the
Welcome window Xcode 5.
First I wanted to show how to
easily create a new project
or a new repository
account in Xcode.
So I'm going to click the Xcode
menu and click preferences.
And we see here I already have
a number of repositories set
up as well as my OS X server.
But I'm going to add a new
repository so I'm going
to hit the plus button
and say add repository.
It's asking me for the
address, I have a snippet
that has a Git hub account in it
and so I'm going to click next.
And now Xcode is verifying my
credentials to this repository
and is now added as a repository
that I can checkout from.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now when I go back
to the Welcome window
and select checkout
an existing project,
we see that that repository
has now been added.
I can also star any of these
repositories and have them show
up in the favorite section.
For now, I'm going to
check out a copy of WebKit.
Now this is the root
URL to the repository
but since there's only one
project on here it was able
to automatically
discover the chunk folder,
the branches folder
and the tags folder
and just showed me the list of
branches I can checkout from.
So I want to check out chunk.
So I'm going to click next and
check that out to my desktop.
So now Xcode is checking
out that working copy
and when it's done it will
search through the Checkout
and find automatically
any Xcode projects
or workspaces and opens them.
If there are more than
one, it'll let you choose
which one you want to open.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So since there's only one it
just showed me the workspace.
And now we can take a look
at the brand new Source
Control menu at the top here.
When I click Source Control
we see the one working copy
that is part of this workspace
and that I just checked
out chunk and so the
current branch is chunk.
All of our branching
operations such as new branch,
switching to branches, merging
branches are all in here.
You can also configure a couple
of options on a working copy.
I'll talk about that later.
There's also a way to get to
checkout from in here as well
as the workspace wide
operations like commit, push,
update, refreshing status.
You can discard all
of the changes and all
of the working copies in
your workspace using Xcode 5.
You can do file, specific
operations like adding,
discarding changes
in a specific file
or marking files
as resolved here.
Let's take a look at this
new history option now.
So I click that and Xcode has
now loaded all the history
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for this workspace.
There's only one working
copy in this workspace
so this is a very simple
view of just that one.
Eric will show you a more
complex example later.
So you can scroll
through all these.
But I know that I have a
specific commit message
that I'm looking for.
So there's now a search
field up here at the top.
I'm curious about
searching for stuff
that touched the CSS support.
So I type in CSS and now
Xcode searched the subversion
repository for commit
messages referencing CSS.
So there's a particular
commit down here
that I was interested in.
So let's take a look
at this one.
We see who committed it,
when it was committed,
the revision number,
the commit message
for this particular commit
and there's also this option
to show the modified
files for this commit.
So when I click that, we now see
a sheet that has all the files
that were changed as part
of that commit and allows me
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to look at the changes.
On the right side here we have
the version of this file prior
to the commit and then on the
left what was actually changed.
So you can just go
through all of these files
and see exactly what
changed in a commit.
So we just took a look at how
to set up an account as well
as a little preview of the
Source Control menu, checkout
and how it can auto
discover branches
for a subversion repository.
And also when you go to set
up in Checkout a new URL
that you've never checked out
from, it'll automatically set
up the account for you,
asking credentials if needed.
But that was a really simple
case for checking out.
Let's talk about more advanced
setups, multiple working copies.
Many projects aggregate
multiple working copies
into a single workspace.
You'll have a repository
for your main app
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and you may be using some Open
Source tools as part of your app
and those come from
different repositories.
Well we want to make
it really easy to set
up new developers on your team.
And we also want to help
you move away from things
like subversion externals
and Git submodules.
Now those work great when
you're always using Git
or always using Subversion but
you might be trying to mix those
and it's hard to have one talk
to the other automatically.
So Xcode's in this
unique position
where it knows all
this information
and can package it
all up for you.
So how's this work?
So when you first open your
project, it contains all
of the working copies into this
metadata that Xcode will use.
You can manage this via the
Source Control menu telling it
to include certain
working copies or not
and whether those are
required to build your project.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So this metadata is
called Source Control data
when committing.
It lives in your workspace
in your shared data folder
as your project name
.xccheckout.
You're going to want to be
committing this so that all
of your other developers
can take advantage
of this new functionality
in Xcode 5.
You can access this new
functionality from the recents
on checking out a
particular project
that you've checkout recently
or when you open a
workspace it sees
that there are missing
working copies
and gives you a dialogue
asking you
to checkout other
working copies.
So let's take a quick
look at this.
All right, so let's go back
to Xcode and we're going
to click checkout an
existing project again.
Now I have a project that's
hosted on our OS X server
and I'm going to check that out.
This particular project
only had one branch
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
so it didn't even ask me which
branch I wanted to checkout.
I'm going to check that
out to the desktop.
And we see Xcode has now
opened the workspace for this
and we can see over
here on the left,
there's another project
reference that is read.
We won't be able to build
unless we have that.
So since I committed the Source
Control data, Xcode is asking me
if I want to checkout
additional working copies
that are required
for this project.
So I'll click checkout
and it found exactly
one that I was missing.
That's the one that contains
this missing project.
So it tells me the name
of the working copy,
where to get it from, allows
me to uncheck it if I decide
that I don't want to actually
check this out right now
and lets me see all of the
branches, this one only has one
so I'm going to keep Master.
When I click next,
it checks it out.
But if we see here on the finder
we have this JogR application
which you may have seen in some
of the other tools sessions,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and now there is this libraries
folder next to it that appeared
after I checked out
additional working copies.
So if I look in there,
there's that working copy.
Xcode knew that as part
of the workspace the
other project was relative
to the main project inside of
a library folder and recreated
that file system
structure for me.
I didn't have to tell it
where to check it out from
or where to check it out to.
So now if I go back to
Xcode, I know that I'm going
to be adding some
more functionality
to this Jogging application
particularly I want
to add swimming support.
I'm not sure why you would want
to go swimming with your phone
but maybe someone will.
So I'm going to go into
my documents folder
where I have this
new SwimKit library.
I'm going to drag it into
the libraries folder,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
look at the project and add
that project into Xcode.
Now Xcode's asking me if I want
to share this working copy.
It realizes that this
is a new working copy
that I didn't have before in
my workspace and wants to know
if I want to add it to
my Source Control data.
I do, so I'm going to click yes.
Now if I look in the Source
Control menu there's now
yet another working copy and it
also says what branch it's on.
Now I want to configure a couple
of options on this working copy
so I'm going to click configure.
Now we see here a
sheet that has a path
to the local working copy,
where it is on my disc,
as well as where it came from,
now that's the information
that we're going to use as
part of the Source Control data
to tell other developers
where to check this out from.
And we have a checkbox to
include this working copy
in that new checkout workflow.
Currently it's set to optional
but I know that we're going
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to soon require this to build.
So I'm going to select required.
There's also a couple
of other options in here
such as configuring remotes
for my Git repository as well
as branches where I can
add and remove branches.
It also shows all of the
remote branches in the remotes.
So now since I just changed
that Source Control data file,
I know that I need to commit
the changes that I did to it
so that all of my coworkers
can take advantage of this.
So I'm going to go to Source
Control, commit and we see
that indeed I did
change that file
and I also changed the
workspace settings file
because I added a new
project to the workspace.
So I'm going to drag
[inaudible] commit message
and we can also push to
remotes automatically
since I'm using Git.
So I'm going to select
push to remotes and then
when I commit two files in push,
it asks me which remotes
I want to push to.
Now pushing it to the
remote makes it so that all
of my coworkers can
get access to it
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
when they update their
local working copies.
So I'm going to commit
and push and now
that that Source Control
data file is updated
so other developers will be
able to automatically checkout
that SwimKit from within Xcode.
First though, I know that since
we're going to be doing a lot
of work on the SwimKit, I'm
going to be adding a new branch
to JogR so that I don't impact
the main line of my code.
So I'm going to select
new branch,
and it asks me what I
want to name my branch.
Since we're adding
swimming support to this,
I think I'll call
it Surf and Turf.
Now when you create a new
branch it automatically branches
from your current branch.
So I'll click create.
So it created the branch and
also as part of creating it,
it automatically switched
to it which I can see here
in the Source Control menu.
Now since I just created
this branch locally in Git,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I know that all my coworkers
are going to be wanting
to make changes to it
as well so I'm going
to push this new branch.
When I go to push we see
that the JogR working
copy now has a new branch
that does not exist
on the remote
and gives me the
option to create it.
So I want to do that and
I'll push that new branch.
Now, since I just added
yet another working copy
to this workspace I know
that any new developers
on our team might want to be
checking that out as well.
So I'm going to actually
switch to my bosses account.
I happen to have his password
although that's not very secure.
So I'll switch to his
account and Xcode's launched
and so I'm going
to click checkout.
He has his OS X server
set up and so it shows all
of the repositories hosted on
his OS X server automatically.
I'm going to click the JogR
repository and check that out.
Now we see because I have
two branches that asks me
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
which one I want to check out.
He's not working on
any new features just
yet so I'm just going
to checkout Master.
It asks me to where I want
to check it out and I'm going
to check it out to my desktop
and it has checked it out.
And it as well has
now asked me to check
out additional working copies
because now there are two
read references to projects
that aren't part of
this workspace just yet.
So I'm going to click checkout
and now it found
those working copies.
And we see here because
I made SwimKit required,
I actually don't have
the option to uncheck it.
When I click next it created
that library folder next to JogR
and has all of those
files ready to go.
All right, so we just saw the
brand new Checkout workflow
and how it's much
more streamlined.
We also saw the branch
integration
in the new checkout workflow
including our multiple working
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
copy support.
We also talked about the
single point to manage accounts
in the accounts preferences.
And the great new Source
Control menu which takes all
of your working copies and
puts them right at the top
of that menu so that you
can easily see them and all
of the branching
workflows as part
of those working copies
are up there as well.
And also showing
the current branch
which I think is really great.
We also showed the new
history with search
and the new Subversion
1.7 support.
So now I'd like to invite
Eric Dudiak up to talk
about collaborating
with OS X server.
[ Applause ]
>> Eric Dudiak: My name is Eric
Dudiak and I'm going to talk
about some of the great
new features we've added
to Xcode 5 and OS X server.
So the Xcode service on OS X
server is a great end-to-end
collaboration tool.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We've added one of the most
requested features to Xcode
which is the hosting of
Git remote repositories.
It has never been easier
to set up a new project
and have both the Git repository
created locally for your project
as well as up on the server.
This is a great way to make
sure your codes always backed
up so there's no
single point of failure
where if you lost a machine,
all your code would be gone.
One of the other great
features of OS X server
and the Xcode service on
it is automated testing.
I'm sure you've seen a lot
about this earlier this week,
is a great feature where you
can see all your unit tests run
continuously on the server.
This gives you a great way to
see when code might regress
and you can use Source
Control to then figure
out what change might have
actually caused that regression.
So every bot when it's run
and does an integration will
show you a list of the commits
that were part of
that integration.
You can then, since
we're integrated
into the ID see exactly what
source changes were made
in the version editor as
part of those commits.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Finally one of the
other great features
of the OS X server is
the archive of releases.
We highly recommend doing
this as a nightly build bot.
And what that will give
you is a great history
of your application as
it's been developed.
Every morning when you come
into work you'll have
a newly built version
of your application that
shows you what's been worked
on in the past day.
This also allows you to
easily track regressions.
You can go back and see previous
versions of your application,
run it on a device and figure
out when a regression
was introduced.
You can then use Source
Control to figure out exactly
which commit caused
that regression once
you've found what day
that roughly happened in.
So for more information about
OS X server and Xcode 5,
I highly recommend reviewing
the Continuous integration
with Xcode 5 session
from earlier this week.
It provided a lot of information
about how to create a bot,
how to set up server
and just a lot of things
that we're not going to have
time to talk about today.
We're going to talk mostly
about the Source Control
and interaction with the server.
So let's look back at those
3 C's of Source Control
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that Kevin was talking
about earlier, confidence,
compartmentalization
and collaboration.
One of the key features
of Source Control
that really brings all
these together is branching.
So I know we've all
been in this position
where maybe you've been
working on your code for a while
and you realize that this
change is really, really big
and you don't ever feel like
you're ready to commit it
into your mainline code.
And then you're in
this situation
where you have all
these changes locally,
either they're committed locally
and you haven't pushed them
to your remote or they're
not even committed.
This is a really bad idea
because now all those
changes are in one place
and you don't have
any backup of them.
Branching is a great
way to get around that.
You can create a branch and then
it's not in your mainline code
and you can work
on it separately.
This gives you the confidence
that your code is always backed
up when you push it to a remote
server or commit to subversion.
This is obviously a key
feature of compartmentalization
because now you can work
on your branch separately
from your mainline code.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Let's say you have an app
already in the App Store
and that's your Master
branch now.
If you want to start working
on version 2.0 of that app,
you'd probably want to
start creating or start
by creating a branch for new
features which aren't going
to be committed to
your mainline code.
So this way if you have to do a
bot update while you're working
on a big feature, you
can quickly switch back
to your mainline branch and
make those small changes
and submit it to the App
Store, then go right back
to your feature branch and
start working on that again.
Finally, branching
is a great way
to collaborate with
your coworkers.
It allows you to be
insulated from all the changes
that they're making while
you're working on a feature.
So you're not constantly dealing
with changes of your coworkers,
you can focus on your feature
and deal with their changes
at the end when you want to
merge it or if you decide
to pull their changes
in at specific points.
It also gives you a great
way to do code reviews.
So if you do all this work
on a branch, when it's time
to merge it you can
simply have one
of your coworkers
actually take a look
at the code and do the merge.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Make sure that you're always
checking each other's code
and that everything works
the way you expect it to.
So as I was saying branches
are great for working in teams.
You don't always want
to see every change
your coworker is making
as you're working
on a big feature,
you want to be somewhat
insulated from that.
So we highly recommend
in Xcode using branches
for developing features.
This is going to keep
your mainline code
from ever getting impacted
by feature development
and so you can quickly release
small updates as needed.
Also with OS X server, that
automated testing I was talking
about and you've heard
about earlier this week is
on a per branch basis.
This means that each
bot is aware
of which branch it's
currently testing
and you can create a new bot
as you create new branches.
This way is unit test
change, you can verify
that each branch
is in a good state.
This is a great way to make
sure that before you merge,
all your code is in the state
that you expect it to be in
and all your unit tests
are running successfully.
So let's look at a
high level concept
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of what exactly is a branch.
So if we have a single
branch here, Master,
represented by two dots,
representing a few commits,
this might be sort of
the existing version
of your app in the App Store.
Now the first thing we're going
to do is create a new branch.
Right now that branch has
nothing different from Master.
It has the exact same code,
it's just essentially a
different name right now.
But the big power
to branching is
that we can commit separately.
So as we start to make
commits to this branch we see
that those changes are only
in orange, they're only
on the branch, they're
not in the Master branch.
And the other great part
is we can still commit
to the Master branch
independently of our new branch.
So we can make features
while still making those
small updates.
And this goes on,
we can continue
to keep these branches
separate up until the point
that we're actually ready to
integrate this great new feature
into our mainline code.
And at that point we'll go ahead
and merge it and now everything
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that was on that branch is now
in the Master branch
or our mainline code.
But let's take a look at
this in a bigger picture.
Let's look at this with OS X
server and working with a team.
So here on the left
this represents sort
of a normal user working
on code on their machine.
They currently have
the Master branch.
And one of their
coworkers has made a branch
on the server and
pushed that up.
So let's talk about
branching with Git.
Git has both local branches
and remote branches.
So in this case the user on
the left does not actually have
that branch yet, it's only
available on the server.
Actually they're also
a little bit behind
on even changes to
the Master branch.
Now since Git is a distributed
Source Control system,
you have to push
and pull in order
to synchronize your local
machine with the server.
So here we're going to
do a pull and we see
that what's happened is we
got the changes on Master
and are now up to date.
And we can continue to make
changes to Master simply
by making a commit locally.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now committing locally in
Git does not push that change
up to the server unless you
specifically tell us to in Xcode
or later push separately.
This is an important distinction
for anyone using Subversion.
But notice that even
though we did a pull,
we still don't have
that branch locally.
In Xcode 5 we've introduced
automatic tracking branches.
A tracking branch is
simply a local branch
that tracks a remote branch.
In this case when I switch
to the branch in Xcode,
I get an automatic local
copy of the same name
that I can start working
with and can merge locally.
Now again all those changes
because Git is distributed
are just local.
And if I want to share all
this work with my coworkers,
I'm going to have to do a push.
A push takes all those changes
and puts them up on the server.
And of course since we all
have unit testing continuous
integration running when the
server sees new commits as part
of a push, it will go ahead
and run the integration
and because I checked
this beforehand,
all those unit tests
will succeed.
So let's take a look at
this in a quick little demo.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So I'm going to login to my
account and I'm also working
on the JogR application.
Now let's open it up and
just as we saw before
since Kevin added a new project
to it with a new working copy,
I also need to check that out.
So let's get that taken
care of real quick.
And we see that it's
automatically used my user name
instead of Kevin's
to check it out.
So great and I have
all the sources.
I can verify that.
I can totally build this project
right now and have no problems.
But I made a deal with Kevin
before we came up on stage here
that if he came up first I
would take a look at his branch
and merge it in with
the Master branch.
So I'm going to go ahead
into the Source Control
menu and look at JogR.
And I'm going to
switch to a branch.
Now the only branch I
have locally is Master
and since I'm already on
that I can't switch to it.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
However, we see that there are
two branches on the server,
Master and Surf and Turf.
So I'm going to switch to
Surf and Turf and take a look
at Kevin's branch and do
a quick code review of it.
This is creating an automatic
tracking branch locally
and switching to Surf and Turf.
If we go back into the Source
Control menu we see that I'm now
on the Surf and Turf branch.
So let's take a look and
rather than doing a really,
looking through all his code,
I'm going to do something
simple.
We wrote a few unit
tests for JogR.
So I'm going to go to the
test navigator and I see
that JogR has four unit tests
and I'm just going to run them.
Easy way to make sure that
Kevin didn't break anything.
Set the build failed.
All right, well let's take
a look at what's happened.
All right, so this is a
normal failure in a unit test.
It looks like something is
probably changed around here
and we can no longer
even build our unit test.
It looks like there's not
this particular initialization
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
method anymore.
So let's take a look
at the run data class
and see what's happen.
So I'm going to hold down
command and select run data
which is going to take me right
to the run data header file
where run data is declared.
And I'll take a look here at
this initialization method.
Pretty sure it looks
a little different
than what I saw before
in the test.
So let's open up the contextual
menu and do show blame for line.
And here we see that it was
indeed changed by Kevin recently
and it seems to be adding
support for Swimming
so it's probably on this
branch that he was playing
around with things and changed
this initialization method.
Now also importantly I can
see that Kevin committed this
at 3:30 a.m. so I'm
going to want
to take a little
closer look at this.
I'm going to go ahead
and show all the files
that he modified this
morning after the Bash.
So I can see that indeed he did
change the initialization method
to support Swimming and
it looks like it now takes
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in an extra boolean that
it didn't have before
in our unit tests.
The rest of this looks
like pretty normal changes.
So I'm going to go ahead
and fix that unit test
by just updating the
use of the initializer.
So now I can go back to
the testing navigator
and run all those unit tests.
This time they succeed
at building
and we're running
in the simulator.
Ah, but I still don't have
green light to cross the board.
Looks like two of them are fine
but two still need a little work
and have changed as a result of
the changes in Surf and Turf.
So looks like a lot of these
are just the result of some
of the assumptions we
were making and some
of our test data has changes
involving Kevin adding new test
data for the Surf
and Turf branch.
Now I can go through
and fix all these
but luckily I have a great
little snippet of code
that just fixes all of them.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So let's rerun the two unit
tests that were failing.
And I can of course with our
new testing support run them one
at a time.
So I can take a look at the two
that failed, run the first one
and now the second one,
all four are green.
I have a lot of confidence
that this is now
in a much better state.
Now since I made
a couple changes,
I need to go ahead
and commit those.
So I'm going to go to the
Source Control menu and commit.
And we see these are just my
updates to the unit tests.
Give it a commit message
and commit the one file.
But now the whole point
of this is I was supposed
to merge Kevin's branch.
So let's go to the Source
Control menu and where I'm
on the Surf and Turf branch
in JogR now, I want to merge
that into the Master branch.
So I'm going to go
to Surf and Turf
and select merge into branch.
There's only one branch that
I can possibly merge this into
and we're discovered
that that's Master.
Xcode will only ever show you
valid branches for merging.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I can go ahead and select that
and it's going to go ahead
and determine all the
potential conflicts and issues
that may come up and it looks
like we might actually have one.
What are the odds?
So actually this happened
in a project file.
Now this is scary.
I don't want to have to
deal with doing a merge
in a project file, that
can't possibly be done.
So it looks like it's
actually not that bad.
It looks like what's happened
is something that happens a lot
which is something, a
resource file was added
on both the Master
branch and Kevin's branch.
So we have a couple of ways we
can resolve the conflict here
and these are all
displayed at the bottom.
I can either select
left and then right.
So this is going to take all
the changes on the left side
which is the Master
branch, take all those
and then take the
changes from Surf and Turf
on the right side after them.
So in this case I'll end up
with both resource files.
This is actually what I
want but let's just look
at the other merge options.
I could take just the left side
which would only give
me the resource file
from the Master branch
and discard the changes
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that were conflicting from
the Surf and Turf branch.
I could also take just
the Surf and Turf changes
or I can take both changes
in the opposite order.
Now in most cases for
project files when dealing
with multiple files being
added, it doesn't matter
which order they're in
but we probably want both.
So I'm just going to
go ahead and take both
of those resource files and make
sure they're in the project.
And it looks like that was
the only conflict we had
so I can go ahead
and select merge.
And since I have Source Control
turned on in a remote server,
I'm not going to bother
with a Snapshot right now.
So now we've done the merge
and we can see that one
of the other things I've set
up for the Master
branch is this JogR bot.
And this JogR bot
will run integrations
so since I already ran the
unit test on the other branch,
I'm reasonably confident
that I can go ahead
and just commit and push this.
So I'm going to go to commit
and we see that I basically had
to resolve that conflict
in addition
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to the normal merge
commit that was added.
So I resolved the
conflict and now
that I've made all the
changes that I need to make
to land Kevin's branch,
I'm going to ahead
and push that to the remote.
I'm pushing now to Master
because I've merged onto Master.
So I'm going to do
a commit and push.
It's going to take all my
working copies and push them
up to the remote server
and I can now go ahead
and fire off an integration
to just double check
that everything I
did commit is good.
Now if we go to the
Source Control menu
as Kevin was saying, we
have this history view.
And I can see that as a result
of the changes that were made,
I have now taken all the support
for Swimming and the merge
and it's now all in
the Master branch.
And here we see an example of
looking at the history sheet
across several working copies.
I can look at all of
them integrated together
so we can get a full
history of the project
or I can see just one at a time.
And again, the search
works across all of them
or whichever ones are selected.
So that's Source
Control in Xcode 5
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with the Continuous
integration Server.
So just to recap
what we saw there
since it can be a
little confusing
to follow what's happening
in branching and merging,
on the left side we see the JogR
branch and we see Kevin's Surf
and Turf branch committed before
a couple changes were made
on the JogR branch but
it's all on the server.
So what I did was I went
ahead and pulled it down
and created a local
tracking branch.
From there I then made
a small commit in order
to fix those unit tests.
This was all local still.
And then I merged it.
Now in order for everyone else
to get the code and I went ahead
and pushed it up to the server.
And then we saw that it fired
a continuous integration
and we can verify the code,
it worked on the server.
So this is very powerful
tool for making sure
that your code's
always in a great state.
So let's review some of
the great new features
of Source Control in Xcode
5 that we've seen today.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We've seen how the new
workflow driven Source Control
interaction is primarily
now accessed
through the top level
Source Control menu
where we have access to
the every working copy
that a project or
workspace is currently using
and what branch we're
currently on in each one.
So this is a great easy way
to quickly see what code
you're working on and be sure
that what you're working
on is what you think
you're working on.
We've also seen some of the
great new server integration
with OS X server and the
Xcode service providing
for the first time
end-to-end solution for Xcode
with one click, get
remote repository creation
with a new project.
And we've seen how we can
automatically manage multiple
working copies so we're
not dealing with a mess
of subversion externals
or get submodules.
We can easily take all this
data, put in a manifest file
in Xcode and share it with
our teammates to make sure
that everyone knows exactly
what they have to have checked
out in order to build
our projects.
This is a very powerful tool
and it just makes getting setup
with a new project for a new
team member so much easier.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Or if you're working
with a large team
and someone adds
something that you need
and they didn't tell
you, it's all automatic.
For more information about Xcode
Source Control or OS X server,
please contact Dave Delong,
he's the app framework
and developer tools
evangelist or ask a question
on the Apple Developer forums.
I'd like to thank you very
much for coming today.
[ Applause ]
[ Silence ]