dvcs_intro_brownbag: slides.rst comparison

comparison slides.rst @ 2:802024c24c4e

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

comparison

equal deleted inserted replaced

-:0c3b42165692
+:802024c24c4e
 .. image:: images/cvcs.png
 ----
+So what's a DVCS look like?
+===========================
+.. image:: images/dvcs.png
+All repositories are peers. By convention only, one repository is designated the master.
+It is possible for all peers to exchange changes.
+----
+What does a DVCS buy you?
+=========================
+- Private workspaces
+- Offline mode
+- Speed
+- Scalability
+- Split Geography
+- Flexible workflows
+- Distributed backups
+- **Easier merging**
+- **Commit before merge**
+----
+Private Workspaces
+==================
+- You can safely experiment in your local repository
+- Commit as often as you like without affecting the team
+- Encourages experimentation
+- Make cheap repository clones to try things out
+- Not visible to coworkers
+----
+Offline Mode
+============
+- Work when you have spotty or no network access
+- Full access to the repo when offline
+- Can work on multiple tasks offline
+- Work on bug report #1
+- Commit
+- Work on bug report #2
+- With a CVCS, you'd have both fixes in the same pending commit
+----
+Speed
+=====
+- Local operations are **fast**
+- No, really, **you will** notice a big difference
+- 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
+a SVN working copy in many cases
+----
+Scalability
+===========
+- Some CVCS systems require heavy weight hardware to support the server
+- E.g. ClearCase with a thousand users
+- With a DVCS, only pushes & pulls contact a central server
+- Most of the work is done locally
+----
+Split Geography
+===============
+- Imagine a team split between Cedar Rapids & Richardson
+- With a CVS, 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
+----
+Flexible Workflows
+==================
+- There is no internal concept of a central repository
+- A central repository exits only by convention
+- More elaborate topologies and workflows can be created:
+- A SW team may push to a central SW repo
+- Periodically changes from the SW repo are pushed to a QA repo
+- Changes from the QA repo can be pushed into a release repo
+----
+Distributed Backups
+===================
+- With a DVCS, multiple copies of the repository exist on multiple machines
+- **Of course, this is no substitute for a real backup strategy!**
+- But usually, and with short notice, you can easily designate a repository as
+the central repository in an emergency
+----
+Easier Merging
+==============
+- Subversion has a bad reputation for merging
+- Some of this is not warranted...
+- Merge tracking was added in SVN v1.5
+- SVN does not handle file renames and tree conflicts very well
+- A lot of teams simply avoid merging out of fear
+----
+Easier Merging (cont.)
+======================
+- Why is merging better in a DVCS?
+- 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
+- More information is available to make merge decisions
+- Easier to find common ancestors of code
+- Developer changes and merge changes are separate
+- "Commit before merge"
+----
+Commit Before Merge
+===================
+- With a CVCS:
+- You make changes in your working copy
+- Before you can commit, you often must peform an update
+- This may trigger a merge
+- Your changes are now mixed up with your friendly coworkers' changes
+- Sometimes this can be a problem...
+- With a DVCS:
+- You make changes in your working copy
+- You commit!
+- You can then choose to pull changes from others and merge
+- **Your changes are already safely tucked away and can be retrieved later if things go wrong**
+----
+Okay, what's the catch?
+=======================
+Potential drawbacks to a DVCS
+-----------------------------
+- Practically no support for locks
+- This makes working with binary files difficult in a team environment
+- Huge repositories are not practical
+- Hetrogenous 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
+----
+Introduction to Mercurial
+=========================
+- Command overview
+- Repositories & working copies
+- Changesets
+- Revisions, changesets, & heads
+- Example workflow
+----
 What is a CVCS Again?
 =====================
 Basic SVN commands:
 ----
 So what's a DVCS look like?
 ===========================
-.. image:: images/dvcs.png
-All repositories are peers. By convention only, one repository is designated the master.
-It is possible for all peers to exchange changes.
-----
-So what's a DVCS look like?
-===========================
 Mercurial (hg) vs SVN commands:
 - add, remove, copy, move, :strike:`mkdir`
 - :strike:`checkout`, commit, update, revert
 - merge, resolve, diff

Mercurial > public > dvcs_intro_brownbag

comparison slides.rst @ 2:802024c24c4e