roslyn on github

Post on 14-Jul-2015

1.011 Views

Category:

Software

5 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Roslyn on GitHubWho let JaredPar pick the infrastructure?

Overview

Git

The basics

Typical workflow

Tools

How we work

Code structure

Transition

Looking forward

Learning GitSHAwhat?

What is this talk?

This is not a definitive guide to Git

Too big a topic for a 1 hour talk

This is a broad overview of Git

Explain the work flow

Introduce the basic commands

Explain the Git mindset

Git is different than TFS or SD

The mindset is the key to learning Git

Remember learning TFS?

Everyone was given a handy command map

sd sync -> tf get . /r

sd commit -> tf checkin

sd branch -> tf branch

sd undo -> tf revert

Don’t learn Git this way

There is no simple command mapping

Git is different

TFS is a black box

It is backed by a SQL server

It has a ASP.Net front end

Developers unconcerned with how data is stored

Git is a very thin layer over the file system

Implementation bleeds into the presentation

Commands directly modify the local file system

Must know how Git works to use it efficiently

Storing Content

Core of Git is a content addressable file system

Key / Value storage

Value can be …

Contents of a file or directory

Description of a change

Key is the checksum of the value (SHA1)

Value is immutable

If the value changes, so does the key

Everything is stored here (commits, files, directories, etc ...)

This mapping is central to the operation of git

Git used to checksums

“Do one thing well” Unix Philosophy

Git does one thing well … checksums

Check sums are used to

Lookup file, directory contents

Sync across machines

Basically everything

SHA-1 hash is 40 characters

Typically referenced by first 6 characters

More used only in face of collisions

Demo Git BasicsIt’s CMD time

Basic Commands

status:

Displays tracked files that have changed

Displays untracked (new) files

add:

Include file in the set of files to be added

Adds file to the object store

commit:

Equivalent of checking files in

Commits

Just another piece of addressable content

Contents

Reference to parent commit objects (0-N)

Reference to a tree object

Set of file names + contents SHA1

Commit Message

Author name

Description of a change

Branches

Content

Reference (SHA-1) to a commit object

Every commit updates the reference

That’s it

Extremely light weight

One file one disk

Content is SHA1 of the current commit

20 bytes per branch

What is in the Git Repo?

Content addressable storage

List of named branches

Each has a SHA1 referring to the latest commit

List of remote repos

URL of the Git repo

Set of branches in the repo

History

Repos have a set of branches

Local and remote

Complete history is available for every branch

Branch points to a commit

Every commit points to its parent (recursive)

Every commit points to its contents

This is distributed version control

My repo is as complete as any other

Working with remotes

Typical naming

upstream: dotnet/roslyn

origin: jaredpar/roslyn

fetch brings down changes from a remote repo

Updates list of branches and their commits

This in turn brings down all the changes for the new commits

fetch is always safe

Never changes the working directory

Manually merge changes later

pull = fetch + merge

Pull requests

All work occurs in personal fork

Developers never commit directly to dotnet/roslyn

Iterate in personal fork until ready for official repo

Create a Pull Request (PR)

Please merge my branch into official repo

All changes to your branch reflected immediately in PR

Developers offer feedback on the PR

Eventually change is accepted and auto-merged into official repo

Demo Git Workflow

The ToolsA UI for Git?

GitHub For Windows

Free application created by GitHub

https://windows.github.com/

Sets up local 2 factor authentication

Use UI or command line without dealing with tokens

Installs standard versions of git on the machine

A mysysgit installation optimized for Windows

Includes posh-git

Automatically, and frequently, updates itself

FxKit

xcopy toolkit developed by CoreFx (Nicholg)

Git environment optimized for DevDiv usage

This is not razzle

No admin requirements, no private toolset

Extending git in supported ways

Gaining traction in corefx

Not intended to be a requirement, just a tool

Other

More fully featured

TortoiseGit: https://code.google.com/p/tortoisegit/

Bare bones installations

MySysGit: https://msysgit.github.io/

Cygwin: https://www.cygwin.com/

Code StructureWhat goes where?

Code flow today

TFS

\Open

\src

\build

\Loc

\Closed

GitHub

\src

\buildOne way pump

Code flow after the switch

TFS

\Open

\Loc

\Closed

GitHub

\src

\buildOne way mirror

\src

\build

Where do I work?

Majority of work is in GitHub

Holds all production code

Holds most of our tooling

All work done in personal forks of dotnet/Roslyn

Start with one branch per change

Code merged into main repot via Pull Requests

Getting a full enlistment

Use SyncGit.ps1

New file in root of TFS repo

Will setup a Git repo inside Open

Direct clone of your fork into Open

The TFS Open directory will be cloaked

Results in same directory layout present today

Can commit to git or TFS from this setup

Cross cutting changes

Changes that affect both Open and Closed

Use a full enlistment

Must be done in Git and TFS

First get code committed to GitHub

Then get the code committed to TFS

Such changes should be rare

If common then probably need to move more to Open

How does code get shipped?

Changes from Git mirrored to TFS

Official builds still come from MicroBuild

MicroBuild process will use TFS

Gets GitHub changes from mirror

Directory structure unchanged from today

Nothing changes about MicroBuild

Components not in public repot

All major components will be in GitHub by 2/7

Smaller items will migrate directly to GitHub after

Feel empowered to move items still in Closed

Only a small number of items can’t be moved

Just check with JaredPar before moving

Looking forward

Git / TFS mix will exist for a few weeks

Give developers time to adjust

Figure out our processes

Let the Open / Closed breakdown settle

Eventually Closed moves to private GitHub repo

Possible move to binary refs between the two

TFS still exists but just for MicroBuild and PDB sources

Please have patience

This is a big change

Working to make it as smooth as possible

That doesn’t make it any smaller

There will be

Hiccups

Unanticipated obstacles

A transition period

Team effort to get us through this

Resources

Pro Git Book (online): http://git-scm.com/book/en/v2

Git SCM Blog: http://git-scm.com/blog

Git Immersion: http://gitimmersion.com/

Just google “git my problem”

More resources than time to read them

top related