# HG changeset patch # User Brian Neal # Date 1320894365 21600 # Node ID 802024c24c4e50050a362d791e278a03874169d6 # Parent 0c3b42165692fcba2c2d78d9aeea947a79812195 More work on the slides. The intro to DVCS part is done (first pass). diff -r 0c3b42165692 -r 802024c24c4e images/dvcs.png Binary file images/dvcs.png has changed diff -r 0c3b42165692 -r 802024c24c4e slides.rst --- a/slides.rst Tue Nov 08 20:52:15 2011 -0600 +++ b/slides.rst Wed Nov 09 21:06:05 2011 -0600 @@ -95,6 +95,203 @@ ---- +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? ===================== @@ -111,16 +308,6 @@ 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`