dvcs_intro_brownbag: slides.rst comparison

comparison slides.rst @ 16:048e5aea6d36 tip

Updates for June 2012 presentation.

author	Brian Neal <bgneal@gmail.com>
date	Mon, 25 Jun 2012 19:51:34 -0500
parents	727c48601d66
children

comparison

equal deleted inserted replaced

-:70e53cce4ad0
+:048e5aea6d36
 Introduction to Distributed Version Control with Mercurial
 ==========================================================
 ----
-(Subliminal Message)
+Agenda
-====================
+======
-.. image:: images/stop.jpg
+- Brief history of version control tools
+- Features of distributed version control
+- Brief introduction to Mercurial
 ----
 # whoami
 ========
 - UMS (July 1999 - Spring 2000)
 - Surgical Strike - (Spring - Fall 2000)
 - JTRS 2B - (Fall 2000 - Summer 2001)
 - SCAMP SEP - (Summer 2001 - October 2004)
 - TTNT (January 2005 - Present)
+----
+Disclaimers
+===========
+- This is not a sales pitch
+- I actually :strike:`like` respect Subversion
+- I'm the "Subversion guy" on my team
+- I developed SVN training and have given it ~9-10 times
+- http://subversion.tigris.org/issues/show_bug.cgi?id=3919
+- I am not an expert
+- I'm probably making this look too easy
+----
+Why learn about DVCS?
+=====================
+- DVCS have exploded in the open source world
+- Interestingly, Subversion is growing in corporate environments
+- Frustration with current tools
+- Interesting to see how the tools have evolved
+- As a software practitioner, you should know what your options are
 ----
 Brief History of Version Control Tools
 ======================================
 - Switching between branches will blow your mind
 - Initial pull down of an entire repository *might* be slower than a CVCS
 - Then again, you might be surprised
-- Mercurial, for example, stores an entire repository in less space than
+- Mercurial, for example, stores an *entire* repository in less space than
 a SVN working copy in many cases
 ----
 - Imagine a team split between Cedar Rapids & Richardson...
 - With a CVCS, you have to pick where to put the server
 - The remote location is stuck with network latency & associated problems
 - With a DVCS, each site can have a central repository
-- The two central repos can be synched when convenient or even scripted
+- The two central repos can be synch'ed when convenient or even scripted
 .. image:: images/split_geography.png
 ----
 - Subversion has a bad reputation for merging
 - Some of this is not warranted...
 - Merge tracking was added in SVN v1.5
+- Steadily improved in v1.6 - v1.7
 - SVN does not handle file renames and tree conflicts very well
-- A lot of teams simply avoid merging out of fear
+- A lot of teams simply avoid merging out of fear or superstition
 ----
 Easier Merging (cont.)
 ======================
 - Merging simply has to work correctly and be easy in a DVCS
 - More attention was paid to this aspect by DVCS's
-- DVCS's use directed acyclic graphs internally to represent change sets
+- DVCS's use **directed acyclic graphs** internally to represent change sets
 - More information is available to make merge decisions
 - Easier to find common ancestors of code
 - Developer changes and merge changes are separate
 ===================
 - With a CVCS:
 - You make changes in your working copy
-- Before you can commit, you often must peform an update
+- Before you can commit, you often must perform an update
 - This may trigger a merge
 - Your changes are now mixed up with your friendly coworkers' changes
 - Sometimes this can be a problem...
 - This makes working with binary files difficult in a team environment
 - Huge repositories are not practical
-- Hetrogenous repositories are not practical
+- Heterogeneous repositories are not practical
 - Not a good idea to mix, say, software, systems, and firmware in the same repo
 - Not a good idea to mix multiple products in the same repo
-- Arguably, this applies to a CVCS as well
+- *Arguably, this applies to a CVCS as well*
 - No support for path-based access control
 - With current tools, you either can access the full repo, or nothing
 - Extensible with official and 3rd party extensions
 - TortoiseHg is a popular GUI for Windows
 - Reputation for being fast & easy to get started with
 - Can be served via Apache Web server
 - Repository hooks
-- Integrates with Trac
+- Integrates with the Trac issue tracker
 - Can import history from other tools, including Subversion
 ----
 Repositories & Working Directories
 - *Regular tags* are revision controlled and propagate to other repos
 - The newest head in a repository is a tag called *tip*
 ----
+A note on branching...
+======================
+- Branching happens *all the time* when multiple developers are involved
+- It is so natural you may not notice it at first
+- Branching often has two meanings:
+- The "normal" day-to-day branching when developers combine changes
+- The conceptual branching that occurs when:
+- You need a feature branch
+- You need a release branch
+- You need an experimental branch
+- etc.
+----
+Ways to Branch in Hg
+====================
+- Just make another clone of the repository!
+- Slowest, safest, easiest to understand
+- Hard links are used (where available) to minimize disk space
+- Bookmarks
+- Lightweight tags can be applied to changesets
+- Similar to how Git does branches
+- Bookmarks can be deleted; they are not permanent
+- Named branches
+- Actually recording the branch name in the changeset
+- Anonymous branches
+- Update to any old changeset, make changes, commit
+- "Good" for emergency fixes, bad for remembering what you did
+----
 Example Workflow
 ================
 .. image:: images/workflow1.png

Mercurial > public > dvcs_intro_brownbag

comparison slides.rst @ 16:048e5aea6d36 tip