Mercurial > public > dvcs_intro_brownbag

annotate slides.rst @ 2:802024c24c4e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
More work on the slides. The intro to DVCS part is done (first pass).
author Brian Neal <bgneal@gmail.com>
date Wed, 09 Nov 2011 21:06:05 -0600
parents 0c3b42165692
children 0130da731f83
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@1 9 (Sublimal Message)
bgneal@1 10 ==================
bgneal@1 11
bgneal@1 12 (We should be using this at work... )
bgneal@1 13 -------------------------------------
bgneal@1 14
bgneal@1 15 (Seriously... )
bgneal@1 16
bgneal@1 17 ----
bgneal@1 18
bgneal@1 19
bgneal@0 20 # whoami
bgneal@0 21 ========
bgneal@0 22
bgneal@0 23 Brian Neal <bgneal1@rockwellcollins.com>
bgneal@0 24
bgneal@0 25 Started at Rockwell Collins in July 1999
bgneal@0 26
bgneal@1 27 Perhaps you've recognized me from the following programs:
bgneal@0 28
bgneal@0 29 - UMS (July 1999 - Spring 2000)
bgneal@0 30 - Surgical Strike - (Spring - Fall 2000)
bgneal@0 31 - JTRS 2B - (Fall 2000 - Summer 2001)
bgneal@0 32 - SCAMP SEP - (Summer 2001 - October 2004)
bgneal@0 33 - TTNT (January 2005 - Present)
bgneal@0 34
bgneal@0 35 ----
bgneal@0 36
bgneal@0 37 Brief History of Version Control Tools
bgneal@0 38 ======================================
bgneal@0 39
bgneal@0 40 First Generation
bgneal@0 41 ----------------
bgneal@0 42
bgneal@1 43 - No networking!
bgneal@1 44 - Concurrency method: locks
bgneal@0 45 - Examples:
bgneal@0 46
bgneal@0 47 - SCCS - 1972
bgneal@0 48 - RCS - 1982
bgneal@0 49
bgneal@0 50 ----
bgneal@0 51
bgneal@0 52 Brief History of Version Control Tools
bgneal@0 53 ======================================
bgneal@0 54
bgneal@0 55 Second Generation
bgneal@0 56 -----------------
bgneal@0 57
bgneal@0 58 - Client/Server networking; CVCS (Centralized Version Control)
bgneal@1 59 - Concurrency method: merge before commit
bgneal@0 60 - Examples:
bgneal@0 61
bgneal@0 62 - CVS - 1990
bgneal@0 63 - IBM Rational ClearCase - 1992
bgneal@0 64 - Visual SourceSafe - 1994
bgneal@0 65 - Perforce - 1995
bgneal@0 66 - SVN - 2000
bgneal@0 67
bgneal@0 68 ----
bgneal@0 69
bgneal@0 70 Brief History of Version Control Tools
bgneal@0 71 ======================================
bgneal@0 72
bgneal@0 73 Third Generation
bgneal@0 74 ----------------
bgneal@0 75
bgneal@0 76 - Distributed networking; DVCS (Distributed Version Control)
bgneal@1 77 - Concurrency method: commit then merge
bgneal@1 78 - Examples:
bgneal@0 79
bgneal@0 80 - Bitkeeper - 2000
bgneal@0 81 - Darcs - 2003
bgneal@0 82 - Monotone - 2003
bgneal@0 83 - Git - 2005
bgneal@0 84 - **Mercurial** - 2005
bgneal@0 85 - Fossil - 2006
bgneal@0 86 - Bazaar - 2007
bgneal@1 87 - Veracity - 2011
bgneal@1 88
bgneal@1 89 ----
bgneal@1 90
bgneal@1 91 What is a CVCS Again?
bgneal@1 92 =====================
bgneal@1 93
bgneal@1 94 .. image:: images/cvcs.png
bgneal@1 95
bgneal@1 96 ----
bgneal@1 97
bgneal@2 98 So what's a DVCS look like?
bgneal@2 99 ===========================
bgneal@2 100
bgneal@2 101 .. image:: images/dvcs.png
bgneal@2 102
bgneal@2 103 All repositories are peers. By convention only, one repository is designated the master.
bgneal@2 104 It is possible for all peers to exchange changes.
bgneal@2 105
bgneal@2 106 ----
bgneal@2 107
bgneal@2 108 What does a DVCS buy you?
bgneal@2 109 =========================
bgneal@2 110
bgneal@2 111 - Private workspaces
bgneal@2 112 - Offline mode
bgneal@2 113 - Speed
bgneal@2 114 - Scalability
bgneal@2 115 - Split Geography
bgneal@2 116 - Flexible workflows
bgneal@2 117 - Distributed backups
bgneal@2 118 - **Easier merging**
bgneal@2 119 - **Commit before merge**
bgneal@2 120
bgneal@2 121 ----
bgneal@2 122
bgneal@2 123 Private Workspaces
bgneal@2 124 ==================
bgneal@2 125
bgneal@2 126 - You can safely experiment in your local repository
bgneal@2 127 - Commit as often as you like without affecting the team
bgneal@2 128 - Encourages experimentation
bgneal@2 129
bgneal@2 130 - Make cheap repository clones to try things out
bgneal@2 131 - Not visible to coworkers
bgneal@2 132
bgneal@2 133 ----
bgneal@2 134
bgneal@2 135 Offline Mode
bgneal@2 136 ============
bgneal@2 137
bgneal@2 138 - Work when you have spotty or no network access
bgneal@2 139 - Full access to the repo when offline
bgneal@2 140 - Can work on multiple tasks offline
bgneal@2 141
bgneal@2 142 - Work on bug report #1
bgneal@2 143 - Commit
bgneal@2 144 - Work on bug report #2
bgneal@2 145 - With a CVCS, you'd have both fixes in the same pending commit
bgneal@2 146
bgneal@2 147 ----
bgneal@2 148
bgneal@2 149 Speed
bgneal@2 150 =====
bgneal@2 151
bgneal@2 152 - Local operations are **fast**
bgneal@2 153 - No, really, **you will** notice a big difference
bgneal@2 154 - Initial pull down of an entire repository *might* be slower than a CVCS
bgneal@2 155
bgneal@2 156 - Then again, you might be surprised
bgneal@2 157 - Mercurial, for example, stores an entire repository in less space than
bgneal@2 158 a SVN working copy in many cases
bgneal@2 159
bgneal@2 160 ----
bgneal@2 161
bgneal@2 162 Scalability
bgneal@2 163 ===========
bgneal@2 164
bgneal@2 165 - Some CVCS systems require heavy weight hardware to support the server
bgneal@2 166
bgneal@2 167 - E.g. ClearCase with a thousand users
bgneal@2 168 - With a DVCS, only pushes & pulls contact a central server
bgneal@2 169 - Most of the work is done locally
bgneal@2 170
bgneal@2 171 ----
bgneal@2 172
bgneal@2 173 Split Geography
bgneal@2 174 ===============
bgneal@2 175
bgneal@2 176 - Imagine a team split between Cedar Rapids & Richardson
bgneal@2 177 - With a CVS, you have to pick where to put the server
bgneal@2 178 - The remote location is stuck with network latency & associated problems
bgneal@2 179 - With a DVCS, each site can have a central repository
bgneal@2 180
bgneal@2 181 - The two central repos can be synched when convenient or even scripted
bgneal@2 182
bgneal@2 183 ----
bgneal@2 184
bgneal@2 185 Flexible Workflows
bgneal@2 186 ==================
bgneal@2 187
bgneal@2 188 - There is no internal concept of a central repository
bgneal@2 189 - A central repository exits only by convention
bgneal@2 190 - More elaborate topologies and workflows can be created:
bgneal@2 191
bgneal@2 192 - A SW team may push to a central SW repo
bgneal@2 193 - Periodically changes from the SW repo are pushed to a QA repo
bgneal@2 194 - Changes from the QA repo can be pushed into a release repo
bgneal@2 195
bgneal@2 196 ----
bgneal@2 197
bgneal@2 198 Distributed Backups
bgneal@2 199 ===================
bgneal@2 200
bgneal@2 201 - With a DVCS, multiple copies of the repository exist on multiple machines
bgneal@2 202 - **Of course, this is no substitute for a real backup strategy!**
bgneal@2 203 - But usually, and with short notice, you can easily designate a repository as
bgneal@2 204 the central repository in an emergency
bgneal@2 205
bgneal@2 206 ----
bgneal@2 207
bgneal@2 208 Easier Merging
bgneal@2 209 ==============
bgneal@2 210
bgneal@2 211 - Subversion has a bad reputation for merging
bgneal@2 212
bgneal@2 213 - Some of this is not warranted...
bgneal@2 214
bgneal@2 215 - Merge tracking was added in SVN v1.5
bgneal@2 216
bgneal@2 217 - SVN does not handle file renames and tree conflicts very well
bgneal@2 218 - A lot of teams simply avoid merging out of fear
bgneal@2 219
bgneal@2 220 ----
bgneal@2 221
bgneal@2 222 Easier Merging (cont.)
bgneal@2 223 ======================
bgneal@2 224
bgneal@2 225 - Why is merging better in a DVCS?
bgneal@2 226
bgneal@2 227 - Merging simply has to work correctly and be easy in a DVCS
bgneal@2 228
bgneal@2 229 - More attention was paid to this aspect by DVCS's
bgneal@2 230
bgneal@2 231 - DVCS's use directed acyclic graphs internally to represent change sets
bgneal@2 232
bgneal@2 233 - More information is available to make merge decisions
bgneal@2 234 - Easier to find common ancestors of code
bgneal@2 235
bgneal@2 236 - Developer changes and merge changes are separate
bgneal@2 237
bgneal@2 238 - "Commit before merge"
bgneal@2 239
bgneal@2 240 ----
bgneal@2 241
bgneal@2 242 Commit Before Merge
bgneal@2 243 ===================
bgneal@2 244
bgneal@2 245 - With a CVCS:
bgneal@2 246
bgneal@2 247 - You make changes in your working copy
bgneal@2 248 - Before you can commit, you often must peform an update
bgneal@2 249
bgneal@2 250 - This may trigger a merge
bgneal@2 251 - Your changes are now mixed up with your friendly coworkers' changes
bgneal@2 252 - Sometimes this can be a problem...
bgneal@2 253
bgneal@2 254 - With a DVCS:
bgneal@2 255
bgneal@2 256 - You make changes in your working copy
bgneal@2 257 - You commit!
bgneal@2 258 - You can then choose to pull changes from others and merge
bgneal@2 259
bgneal@2 260 - **Your changes are already safely tucked away and can be retrieved later if things go wrong**
bgneal@2 261
bgneal@2 262 ----
bgneal@2 263
bgneal@2 264 Okay, what's the catch?
bgneal@2 265 =======================
bgneal@2 266
bgneal@2 267 Potential drawbacks to a DVCS
bgneal@2 268 -----------------------------
bgneal@2 269
bgneal@2 270 - Practically no support for locks
bgneal@2 271
bgneal@2 272 - This makes working with binary files difficult in a team environment
bgneal@2 273
bgneal@2 274 - Huge repositories are not practical
bgneal@2 275
bgneal@2 276 - Hetrogenous repositories are not practical
bgneal@2 277
bgneal@2 278 - Not a good idea to mix, say, software, systems, and firmware in the same repo
bgneal@2 279 - Not a good idea to mix multiple products in the same repo
bgneal@2 280 - Arguably, this applies to a CVCS as well
bgneal@2 281
bgneal@2 282 ----
bgneal@2 283
bgneal@2 284 Introduction to Mercurial
bgneal@2 285 =========================
bgneal@2 286
bgneal@2 287 - Command overview
bgneal@2 288 - Repositories & working copies
bgneal@2 289 - Changesets
bgneal@2 290 - Revisions, changesets, & heads
bgneal@2 291 - Example workflow
bgneal@2 292
bgneal@2 293 ----
bgneal@2 294
bgneal@1 295 What is a CVCS Again?
bgneal@1 296 =====================
bgneal@1 297
bgneal@1 298 Basic SVN commands:
bgneal@1 299
bgneal@1 300 - add, remove, copy, move, mkdir
bgneal@1 301 - checkout, commit, update, revert
bgneal@1 302 - merge, resolved, diff
bgneal@1 303 - status
bgneal@1 304 - lock, unlock
bgneal@1 305
bgneal@1 306 ----
bgneal@1 307
bgneal@1 308 So what's a DVCS look like?
bgneal@1 309 ===========================
bgneal@1 310
bgneal@1 311 Mercurial (hg) vs SVN commands:
bgneal@1 312
bgneal@1 313 - add, remove, copy, move, :strike:`mkdir`
bgneal@1 314 - :strike:`checkout`, commit, update, revert
bgneal@1 315 - merge, resolve, diff
bgneal@1 316 - status
bgneal@1 317 - :strike:`lock, unlock`
bgneal@1 318
bgneal@1 319 Additional "distributed commands":
bgneal@1 320
bgneal@1 321 - clone, push, pull
bgneal@1 322 - incoming, outgoing
bgneal@1 323 - serve
bgneal@1 324