Mercurial > public > dvcs_intro_brownbag

annotate slides.rst @ 3:0130da731f83

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
More work on the presentation.
author Brian Neal <bgneal@gmail.com>
date Thu, 10 Nov 2011 22:04:38 -0600
parents 802024c24c4e
children c9a18db51976
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@3 257 - You commit locally!
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 - Repositories & working copies
bgneal@2 288 - Changesets
bgneal@2 289 - Revisions, changesets, & heads
bgneal@3 290 - Command overview
bgneal@2 291 - Example workflow
bgneal@2 292
bgneal@2 293 ----
bgneal@2 294
bgneal@3 295 Repositories & Working Copies
bgneal@3 296 =============================
bgneal@3 297
bgneal@3 298 A repository consists of two things:
bgneal@3 299
bgneal@3 300 - Your working copy (a directory tree of files)
bgneal@3 301 - The repository itself (also known as "the store")
bgneal@3 302
bgneal@3 303 - A .hg directory at the top of your working copy
bgneal@3 304
bgneal@3 305 Example::
bgneal@3 306
bgneal@3 307 brian@gremmie:~/Documents/Rockwell/brownbags/dvcs/dvcs$ la
bgneal@3 308 .hg .hgignore images/ slides.cfg slides.css slides.html slides.rst
bgneal@3 309
bgneal@3 310 ----
bgneal@3 311
bgneal@3 312 What's in a Repository?
bgneal@3 313 =======================
bgneal@3 314
bgneal@3 315 A repository consists of a directed, acyclic graph of *changesets*
bgneal@3 316
bgneal@3 317 .. image:: images/repos.png
bgneal@3 318
bgneal@3 319 - Each changeset can have 0, 1, or 2 parents
bgneal@3 320 - A changeset with 0 parents is the root
bgneal@3 321 - A changeset with 2 parents is the result of a merge
bgneal@3 322 - The newest changeset is called the *tip*
bgneal@3 323
bgneal@3 324 ----
bgneal@3 325
bgneal@3 326 SVN Commands for Review
bgneal@3 327 =======================
bgneal@1 328
bgneal@1 329 Basic SVN commands:
bgneal@1 330
bgneal@1 331 - add, remove, copy, move, mkdir
bgneal@1 332 - checkout, commit, update, revert
bgneal@1 333 - merge, resolved, diff
bgneal@1 334 - status
bgneal@1 335 - lock, unlock
bgneal@1 336
bgneal@1 337 ----
bgneal@1 338
bgneal@3 339 Mercurial Commands
bgneal@3 340 ==================
bgneal@1 341
bgneal@1 342 Mercurial (hg) vs SVN commands:
bgneal@1 343
bgneal@1 344 - add, remove, copy, move, :strike:`mkdir`
bgneal@1 345 - :strike:`checkout`, commit, update, revert
bgneal@1 346 - merge, resolve, diff
bgneal@1 347 - status
bgneal@1 348 - :strike:`lock, unlock`
bgneal@1 349
bgneal@1 350 Additional "distributed commands":
bgneal@1 351
bgneal@1 352 - clone, push, pull
bgneal@1 353 - incoming, outgoing
bgneal@1 354 - serve
bgneal@1 355