annotate 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
rev   line source
bgneal@1 1 .. role:: strike
bgneal@1 2 :class: strike
bgneal@1 3
bgneal@0 4 Introduction to Distributed Version Control with Mercurial
bgneal@0 5 ==========================================================
bgneal@0 6
bgneal@0 7 ----
bgneal@0 8
bgneal@16 9 Agenda
bgneal@16 10 ======
bgneal@1 11
bgneal@16 12 - Brief history of version control tools
bgneal@16 13 - Features of distributed version control
bgneal@16 14 - Brief introduction to Mercurial
bgneal@1 15
bgneal@1 16 ----
bgneal@1 17
bgneal@0 18 # whoami
bgneal@0 19 ========
bgneal@0 20
bgneal@0 21 Brian Neal <bgneal1@rockwellcollins.com>
bgneal@0 22
bgneal@0 23 Started at Rockwell Collins in July 1999
bgneal@0 24
bgneal@5 25 You might remember me from the following programs:
bgneal@0 26
bgneal@0 27 - UMS (July 1999 - Spring 2000)
bgneal@0 28 - Surgical Strike - (Spring - Fall 2000)
bgneal@0 29 - JTRS 2B - (Fall 2000 - Summer 2001)
bgneal@0 30 - SCAMP SEP - (Summer 2001 - October 2004)
bgneal@0 31 - TTNT (January 2005 - Present)
bgneal@0 32
bgneal@0 33 ----
bgneal@0 34
bgneal@16 35 Disclaimers
bgneal@16 36 ===========
bgneal@16 37
bgneal@16 38 - This is not a sales pitch
bgneal@16 39 - I actually :strike:`like` respect Subversion
bgneal@16 40
bgneal@16 41 - I'm the "Subversion guy" on my team
bgneal@16 42 - I developed SVN training and have given it ~9-10 times
bgneal@16 43 - http://subversion.tigris.org/issues/show_bug.cgi?id=3919
bgneal@16 44
bgneal@16 45 - I am not an expert
bgneal@16 46
bgneal@16 47 - I'm probably making this look too easy
bgneal@16 48
bgneal@16 49 ----
bgneal@16 50
bgneal@16 51 Why learn about DVCS?
bgneal@16 52 =====================
bgneal@16 53
bgneal@16 54 - DVCS have exploded in the open source world
bgneal@16 55
bgneal@16 56 - Interestingly, Subversion is growing in corporate environments
bgneal@16 57
bgneal@16 58 - Frustration with current tools
bgneal@16 59 - Interesting to see how the tools have evolved
bgneal@16 60
bgneal@16 61 - As a software practitioner, you should know what your options are
bgneal@16 62
bgneal@16 63 ----
bgneal@16 64
bgneal@0 65 Brief History of Version Control Tools
bgneal@0 66 ======================================
bgneal@0 67
bgneal@0 68 First Generation
bgneal@0 69 ----------------
bgneal@0 70
bgneal@1 71 - No networking!
bgneal@1 72 - Concurrency method: locks
bgneal@0 73 - Examples:
bgneal@0 74
bgneal@0 75 - SCCS - 1972
bgneal@0 76 - RCS - 1982
bgneal@0 77
bgneal@0 78 ----
bgneal@0 79
bgneal@0 80 Brief History of Version Control Tools
bgneal@0 81 ======================================
bgneal@0 82
bgneal@0 83 Second Generation
bgneal@0 84 -----------------
bgneal@0 85
bgneal@0 86 - Client/Server networking; CVCS (Centralized Version Control)
bgneal@1 87 - Concurrency method: merge before commit
bgneal@0 88 - Examples:
bgneal@0 89
bgneal@0 90 - CVS - 1990
bgneal@0 91 - IBM Rational ClearCase - 1992
bgneal@0 92 - Visual SourceSafe - 1994
bgneal@0 93 - Perforce - 1995
bgneal@0 94 - SVN - 2000
bgneal@0 95
bgneal@0 96 ----
bgneal@0 97
bgneal@0 98 Brief History of Version Control Tools
bgneal@0 99 ======================================
bgneal@0 100
bgneal@0 101 Third Generation
bgneal@0 102 ----------------
bgneal@0 103
bgneal@0 104 - Distributed networking; DVCS (Distributed Version Control)
bgneal@1 105 - Concurrency method: commit then merge
bgneal@1 106 - Examples:
bgneal@0 107
bgneal@0 108 - Bitkeeper - 2000
bgneal@0 109 - Darcs - 2003
bgneal@0 110 - Monotone - 2003
bgneal@0 111 - Git - 2005
bgneal@0 112 - **Mercurial** - 2005
bgneal@0 113 - Fossil - 2006
bgneal@0 114 - Bazaar - 2007
bgneal@1 115 - Veracity - 2011
bgneal@1 116
bgneal@1 117 ----
bgneal@1 118
bgneal@1 119 What is a CVCS Again?
bgneal@1 120 =====================
bgneal@1 121
bgneal@1 122 .. image:: images/cvcs.png
bgneal@1 123
bgneal@1 124 ----
bgneal@1 125
bgneal@2 126 So what's a DVCS look like?
bgneal@2 127 ===========================
bgneal@2 128
bgneal@2 129 .. image:: images/dvcs.png
bgneal@2 130
bgneal@2 131 All repositories are peers. By convention only, one repository is designated the master.
bgneal@6 132 It is possible for all peers to exchange changes (via *push* and *pull* operations).
bgneal@2 133
bgneal@2 134 ----
bgneal@2 135
bgneal@2 136 What does a DVCS buy you?
bgneal@2 137 =========================
bgneal@2 138
bgneal@2 139 - Private workspaces
bgneal@2 140 - Offline mode
bgneal@2 141 - Speed
bgneal@2 142 - Scalability
bgneal@2 143 - Split Geography
bgneal@2 144 - Flexible workflows
bgneal@2 145 - Distributed backups
bgneal@2 146 - **Easier merging**
bgneal@2 147 - **Commit before merge**
bgneal@2 148
bgneal@2 149 ----
bgneal@2 150
bgneal@2 151 Private Workspaces
bgneal@2 152 ==================
bgneal@2 153
bgneal@2 154 - You can safely experiment in your local repository
bgneal@2 155 - Commit as often as you like without affecting the team
bgneal@10 156
bgneal@10 157 - Encourages "micro-commits"
bgneal@10 158 - With SVN, people often hold back until an entire feature is complete
bgneal@10 159
bgneal@2 160 - Encourages experimentation
bgneal@2 161
bgneal@2 162 - Make cheap repository clones to try things out
bgneal@2 163 - Not visible to coworkers
bgneal@2 164
bgneal@2 165 ----
bgneal@2 166
bgneal@2 167 Offline Mode
bgneal@2 168 ============
bgneal@2 169
bgneal@2 170 - Work when you have spotty or no network access
bgneal@2 171 - Full access to the repo when offline
bgneal@2 172 - Can work on multiple tasks offline
bgneal@2 173
bgneal@2 174 - Work on bug report #1
bgneal@2 175 - Commit
bgneal@2 176 - Work on bug report #2
bgneal@2 177 - With a CVCS, you'd have both fixes in the same pending commit
bgneal@2 178
bgneal@2 179 ----
bgneal@2 180
bgneal@2 181 Speed
bgneal@2 182 =====
bgneal@2 183
bgneal@2 184 - Local operations are **fast**
bgneal@8 185
bgneal@8 186 - No, really, **you will** notice a big difference
bgneal@8 187 - Switching between branches will blow your mind
bgneal@8 188
bgneal@2 189 - Initial pull down of an entire repository *might* be slower than a CVCS
bgneal@2 190
bgneal@2 191 - Then again, you might be surprised
bgneal@16 192 - Mercurial, for example, stores an *entire* repository in less space than
bgneal@2 193 a SVN working copy in many cases
bgneal@8 194
bgneal@2 195
bgneal@2 196 ----
bgneal@2 197
bgneal@2 198 Scalability
bgneal@2 199 ===========
bgneal@2 200
bgneal@2 201 - Some CVCS systems require heavy weight hardware to support the server
bgneal@2 202
bgneal@2 203 - E.g. ClearCase with a thousand users
bgneal@2 204 - With a DVCS, only pushes & pulls contact a central server
bgneal@2 205 - Most of the work is done locally
bgneal@2 206
bgneal@2 207 ----
bgneal@2 208
bgneal@2 209 Split Geography
bgneal@2 210 ===============
bgneal@2 211
bgneal@6 212 - Imagine a team split between Cedar Rapids & Richardson...
bgneal@10 213 - With a CVCS, you have to pick where to put the server
bgneal@2 214 - The remote location is stuck with network latency & associated problems
bgneal@2 215 - With a DVCS, each site can have a central repository
bgneal@2 216
bgneal@16 217 - The two central repos can be synch'ed when convenient or even scripted
bgneal@2 218
bgneal@9 219 .. image:: images/split_geography.png
bgneal@9 220
bgneal@2 221 ----
bgneal@2 222
bgneal@2 223 Flexible Workflows
bgneal@2 224 ==================
bgneal@2 225
bgneal@2 226 - There is no internal concept of a central repository
bgneal@2 227 - A central repository exits only by convention
bgneal@2 228 - More elaborate topologies and workflows can be created:
bgneal@2 229
bgneal@2 230 - A SW team may push to a central SW repo
bgneal@2 231 - Periodically changes from the SW repo are pushed to a QA repo
bgneal@2 232 - Changes from the QA repo can be pushed into a release repo
bgneal@9 233
bgneal@9 234 .. image:: images/flexible_workflows.png
bgneal@2 235
bgneal@2 236 ----
bgneal@2 237
bgneal@2 238 Distributed Backups
bgneal@2 239 ===================
bgneal@2 240
bgneal@2 241 - With a DVCS, multiple copies of the repository exist on multiple machines
bgneal@2 242 - **Of course, this is no substitute for a real backup strategy!**
bgneal@2 243 - But usually, and with short notice, you can easily designate a repository as
bgneal@2 244 the central repository in an emergency
bgneal@2 245
bgneal@2 246 ----
bgneal@2 247
bgneal@2 248 Easier Merging
bgneal@2 249 ==============
bgneal@2 250
bgneal@2 251 - Subversion has a bad reputation for merging
bgneal@2 252
bgneal@2 253 - Some of this is not warranted...
bgneal@2 254
bgneal@2 255 - Merge tracking was added in SVN v1.5
bgneal@16 256 - Steadily improved in v1.6 - v1.7
bgneal@2 257
bgneal@2 258 - SVN does not handle file renames and tree conflicts very well
bgneal@16 259 - A lot of teams simply avoid merging out of fear or superstition
bgneal@2 260
bgneal@2 261 ----
bgneal@2 262
bgneal@2 263 Easier Merging (cont.)
bgneal@2 264 ======================
bgneal@2 265
bgneal@2 266 - Why is merging better in a DVCS?
bgneal@2 267
bgneal@2 268 - Merging simply has to work correctly and be easy in a DVCS
bgneal@2 269
bgneal@2 270 - More attention was paid to this aspect by DVCS's
bgneal@2 271
bgneal@16 272 - DVCS's use **directed acyclic graphs** internally to represent change sets
bgneal@2 273
bgneal@2 274 - More information is available to make merge decisions
bgneal@2 275 - Easier to find common ancestors of code
bgneal@2 276
bgneal@2 277 - Developer changes and merge changes are separate
bgneal@2 278
bgneal@2 279 - "Commit before merge"
bgneal@2 280
bgneal@2 281 ----
bgneal@2 282
bgneal@2 283 Commit Before Merge
bgneal@2 284 ===================
bgneal@2 285
bgneal@2 286 - With a CVCS:
bgneal@2 287
bgneal@2 288 - You make changes in your working copy
bgneal@16 289 - Before you can commit, you often must perform an update
bgneal@2 290
bgneal@2 291 - This may trigger a merge
bgneal@2 292 - Your changes are now mixed up with your friendly coworkers' changes
bgneal@2 293 - Sometimes this can be a problem...
bgneal@2 294
bgneal@2 295 - With a DVCS:
bgneal@2 296
bgneal@2 297 - You make changes in your working copy
bgneal@3 298 - You commit locally!
bgneal@2 299 - You can then choose to pull changes from others and merge
bgneal@2 300
bgneal@2 301 - **Your changes are already safely tucked away and can be retrieved later if things go wrong**
bgneal@2 302
bgneal@2 303 ----
bgneal@2 304
bgneal@2 305 Okay, what's the catch?
bgneal@2 306 =======================
bgneal@2 307
bgneal@2 308 Potential drawbacks to a DVCS
bgneal@2 309 -----------------------------
bgneal@2 310
bgneal@2 311 - Practically no support for locks
bgneal@2 312
bgneal@2 313 - This makes working with binary files difficult in a team environment
bgneal@2 314
bgneal@2 315 - Huge repositories are not practical
bgneal@2 316
bgneal@16 317 - Heterogeneous repositories are not practical
bgneal@2 318
bgneal@2 319 - Not a good idea to mix, say, software, systems, and firmware in the same repo
bgneal@2 320 - Not a good idea to mix multiple products in the same repo
bgneal@16 321 - *Arguably, this applies to a CVCS as well*
bgneal@2 322
bgneal@7 323 - No support for path-based access control
bgneal@7 324
bgneal@7 325 - With current tools, you either can access the full repo, or nothing
bgneal@7 326
bgneal@2 327 ----
bgneal@2 328
bgneal@2 329 Introduction to Mercurial
bgneal@2 330 =========================
bgneal@2 331
bgneal@5 332 - Overview
bgneal@6 333 - Repositories & working directories
bgneal@2 334 - Changesets
bgneal@4 335 - Branches & Tags
bgneal@4 336 - Example workflow
bgneal@3 337 - Command overview
bgneal@2 338
bgneal@2 339 ----
bgneal@2 340
bgneal@5 341 Mercurial Overview
bgneal@5 342 ==================
bgneal@5 343
bgneal@5 344 - Distributed Version Control System
bgneal@5 345 - Free, open source software licensed under GPL Version 2
bgneal@5 346 - Available for Microsoft Windows, GNU/Linux, Mac OS X, Solaris 11 Express
bgneal@5 347 - Written in Python with a small amount of C
bgneal@5 348 - Extensible with official and 3rd party extensions
bgneal@5 349 - TortoiseHg is a popular GUI for Windows
bgneal@5 350 - Reputation for being fast & easy to get started with
bgneal@5 351 - Can be served via Apache Web server
bgneal@5 352 - Repository hooks
bgneal@16 353 - Integrates with the Trac issue tracker
bgneal@5 354 - Can import history from other tools, including Subversion
bgneal@5 355
bgneal@5 356 ----
bgneal@5 357
bgneal@6 358 Repositories & Working Directories
bgneal@6 359 ==================================
bgneal@3 360
bgneal@3 361 A repository consists of two things:
bgneal@3 362
bgneal@4 363 - Your working directory (similar to a working copy in SVN)
bgneal@3 364 - The repository itself (also known as "the store")
bgneal@3 365
bgneal@3 366 - A .hg directory at the top of your working copy
bgneal@3 367
bgneal@3 368 Example::
bgneal@3 369
bgneal@4 370 $ ls -A
bgneal@3 371 .hg .hgignore images/ slides.cfg slides.css slides.html slides.rst
bgneal@3 372
bgneal@6 373 - Repositories communicate via the *push* and *pull* commands
bgneal@6 374
bgneal@6 375 - Push & Pull do not affect your working directory
bgneal@6 376
bgneal@6 377 - An *update* or *merge* must be performed to receive remote changes into your working directory
bgneal@6 378
bgneal@3 379 ----
bgneal@3 380
bgneal@3 381 What's in a Repository?
bgneal@3 382 =======================
bgneal@3 383
bgneal@3 384 A repository consists of a directed, acyclic graph of *changesets*
bgneal@3 385
bgneal@3 386 .. image:: images/repos.png
bgneal@3 387
bgneal@4 388 - Each changeset can have 0, 1, or 2 parents (and infinite children)
bgneal@3 389 - A changeset with 0 parents is the root
bgneal@3 390 - A changeset with 2 parents is the result of a merge
bgneal@4 391 - The newest changeset is called the *tip*, a special tag name
bgneal@4 392
bgneal@4 393 ----
bgneal@4 394
bgneal@4 395 What's a Changeset?
bgneal@4 396 ===================
bgneal@4 397
bgneal@4 398 A changeset is an atomic collection of changes and some meta information.
bgneal@4 399 The meta information includes:
bgneal@4 400
bgneal@4 401 - Who made the changes
bgneal@4 402 - When the changes were made
bgneal@4 403 - Why - the commit message
bgneal@4 404 - The name of the branch the changes were made on ("default" is the default)
bgneal@4 405 - A local revision number
bgneal@4 406 - A changeset ID; a 40 digit hex number (SHA-1 hash of the changeset & parents)
bgneal@4 407
bgneal@4 408 A changeset can be named by:
bgneal@4 409
bgneal@4 410 - Revision number (within a repository)
bgneal@4 411 - Changeset ID (globally)
bgneal@4 412 - Tag name
bgneal@4 413
bgneal@4 414 ----
bgneal@4 415
bgneal@4 416 Branches & Tags
bgneal@4 417 ===============
bgneal@4 418
bgneal@4 419 - In the simple case, each changeset appear in a line
bgneal@4 420 - When a changeset develops 2 or more children, a branch occurs
bgneal@4 421
bgneal@4 422 - The latest revision of a branch is called a *head*
bgneal@4 423 - A *merge* is when two branches join back together
bgneal@4 424 - Branches can be given names; the default branch name is *"default"*
bgneal@4 425
bgneal@4 426 - Changesets can be given human readable names, or *tags*
bgneal@4 427
bgneal@4 428 - *Local tags* are only visible within a repository
bgneal@4 429 - *Regular tags* are revision controlled and propagate to other repos
bgneal@4 430 - The newest head in a repository is a tag called *tip*
bgneal@4 431
bgneal@4 432 ----
bgneal@4 433
bgneal@16 434 A note on branching...
bgneal@16 435 ======================
bgneal@16 436
bgneal@16 437 - Branching happens *all the time* when multiple developers are involved
bgneal@16 438 - It is so natural you may not notice it at first
bgneal@16 439 - Branching often has two meanings:
bgneal@16 440
bgneal@16 441 - The "normal" day-to-day branching when developers combine changes
bgneal@16 442 - The conceptual branching that occurs when:
bgneal@16 443
bgneal@16 444 - You need a feature branch
bgneal@16 445 - You need a release branch
bgneal@16 446 - You need an experimental branch
bgneal@16 447 - etc.
bgneal@16 448
bgneal@16 449 ----
bgneal@16 450
bgneal@16 451 Ways to Branch in Hg
bgneal@16 452 ====================
bgneal@16 453
bgneal@16 454 - Just make another clone of the repository!
bgneal@16 455
bgneal@16 456 - Slowest, safest, easiest to understand
bgneal@16 457 - Hard links are used (where available) to minimize disk space
bgneal@16 458
bgneal@16 459 - Bookmarks
bgneal@16 460
bgneal@16 461 - Lightweight tags can be applied to changesets
bgneal@16 462 - Similar to how Git does branches
bgneal@16 463 - Bookmarks can be deleted; they are not permanent
bgneal@16 464
bgneal@16 465 - Named branches
bgneal@16 466
bgneal@16 467 - Actually recording the branch name in the changeset
bgneal@16 468
bgneal@16 469 - Anonymous branches
bgneal@16 470
bgneal@16 471 - Update to any old changeset, make changes, commit
bgneal@16 472 - "Good" for emergency fixes, bad for remembering what you did
bgneal@16 473
bgneal@16 474 ----
bgneal@16 475
bgneal@4 476 Example Workflow
bgneal@4 477 ================
bgneal@4 478
bgneal@4 479 .. image:: images/workflow1.png
bgneal@4 480
bgneal@4 481 ----
bgneal@4 482
bgneal@4 483 Example Workflow (cont.)
bgneal@4 484 ========================
bgneal@4 485
bgneal@4 486 .. image:: images/workflow2.png
bgneal@4 487
bgneal@4 488 ----
bgneal@4 489
bgneal@4 490 Example Workflow (cont.)
bgneal@4 491 ========================
bgneal@4 492
bgneal@4 493 .. image:: images/workflow3.png
bgneal@3 494
bgneal@6 495 - Notice that after Alice's pull:
bgneal@6 496
bgneal@6 497 - Her working directory is unaffected
bgneal@6 498 - Her repository only has one head => no merging required
bgneal@6 499
bgneal@6 500
bgneal@3 501 ----
bgneal@3 502
bgneal@3 503 SVN Commands for Review
bgneal@3 504 =======================
bgneal@1 505
bgneal@1 506 Basic SVN commands:
bgneal@1 507
bgneal@1 508 - add, remove, copy, move, mkdir
bgneal@1 509 - checkout, commit, update, revert
bgneal@1 510 - merge, resolved, diff
bgneal@4 511 - status, log
bgneal@1 512 - lock, unlock
bgneal@1 513
bgneal@1 514 ----
bgneal@1 515
bgneal@4 516 Basic Mercurial Commands
bgneal@4 517 ========================
bgneal@1 518
bgneal@1 519 Mercurial (hg) vs SVN commands:
bgneal@1 520
bgneal@1 521 - add, remove, copy, move, :strike:`mkdir`
bgneal@1 522 - :strike:`checkout`, commit, update, revert
bgneal@4 523 - merge, resolve, diff, **heads**
bgneal@4 524 - status, log
bgneal@1 525 - :strike:`lock, unlock`
bgneal@1 526
bgneal@1 527 Additional "distributed commands":
bgneal@1 528
bgneal@5 529 - **clone**, **push**, **pull**
bgneal@5 530 - **incoming**, **outgoing**
bgneal@1 531
bgneal@4 532 **Not a whole lot to learn above SVN**
bgneal@4 533
bgneal@4 534 ----
bgneal@4 535
bgneal@4 536 References
bgneal@4 537 ==========
bgneal@4 538
bgneal@4 539 - Mercurial http://mercurial.selenic.com/
bgneal@4 540 - Mercurial Wiki http://mercurial.selenic.com/wiki/
bgneal@4 541 - Mercurial Book (free!) http://hgbook.red-bean.com/
bgneal@4 542 - Hg Init: A Mercurial Tutorial http://hginit.com
bgneal@4 543 - Version Control By Example (free!) http://www.ericsink.com/vcbe/
bgneal@4 544
bgneal@5 545 This presentation is available at::
bgneal@5 546
bgneal@5 547 $ hg clone https://bitbucket.org/bgneal/dvcs_intro_brownbag
bgneal@5 548
bgneal@4 549 ----
bgneal@4 550
bgneal@4 551 Questions?
bgneal@4 552 ==========
bgneal@4 553