• Save

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

Share

Dscm barcelona

  • 2,566 views
Uploaded on

Distributed Source Code Management. Evolution of SCM, Centralised V's Distributed and then a comparison of the core concepts of Mercurial, Git and Bazaar.

Distributed Source Code Management. Evolution of SCM, Centralised V's Distributed and then a comparison of the core concepts of Mercurial, Git and Bazaar.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,566
On Slideshare
2,566
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • <br />
  • Writing software for 11 years (Java, Ruby, Php) - (Sun, DB, Betfair?) <br /> Clearcase, CVS, SVN, Git <br /> In Valencia for 8 years <br /> Ask questions at any time - English or Spanish <br />
  • Version control vital <br /> Only part of project success- No golden bullet <br /> Definition, Evolution, SVN vs Distributed (Git), Mercurial/Git/Bazaar -> A little advice. <br /> Aim - to give you the knowledge to make an informed choice given your projects&#x2019; context. <br /> <br />
  • Disaster recovery <br /> Multiple simultaneous versions <br /> Traceability <br /> Collaboration - who, when (and WHY if you&#x2019;re lucky!) <br />
  • Three generations of SCM tools <br /> Drivers -> shortcomings of existing tools + improvements in technology (connectivity) <br /> I forget to unlock and you can&#x2019;t write to the file <br />
  • CVS used RCS as a building block. <br /> TeamWare used SCCS - first system with no notion of a central repo (EOL). <br /> CVS - simultaneous changes stored individually and poor file hierarchy management <br /> Subversion - multi-file atomic commits, better namespaces <br /> Visual SourceSafe (Microsoft) - read the web page, it puts the fear of God into me. <br /> <br /> <br />
  • Linux was using BitKeeper. Was one of the first to allow a truly distributed model <br /> Bazaar - Ubuntu, MySQL <br /> Mercurial - Firefox, Opera, CodeIgniter, Google <br /> Git - Facebook, Twitter, jQuery, Rails <br />
  • Everything is local, faster <br /> Backups are every contributor&#x2019;s copy <br /> Flexibility - Tools don&#x2019;t dictate your workflow <br />
  • .svn files pollute your local directories. <br /> Offline commits are not possible. <br /> No way to push changes to another user (without submitting to the Central Server). <br /> <br /> Subversion fails to merge changes when files or directories are renamed. <br /> Major reason is that branching is easy but merging is a pain. <br />
  • .svn files pollute your local directories. <br /> Offline commits are not possible. <br /> No way to push changes to another user (without submitting to the Central Server). <br /> <br /> Subversion fails to merge changes when files or directories are renamed. <br /> Major reason is that branching is easy but merging is a pain. <br />
  • Social Coding <br /> LaunchPad - Pretty basic experience, 5 min wait for web to update, Loggerhead viewer <br /> Google Code supports Mercurial too but over http <br /> <br />
  • <br /> <br /> <br />
  • quite a good user experience <br /> <br /> <br />
  • Smoothest experience <br /> <br /> <br />
  • LaunchPad - Pretty basic experience, 5 min wait for web to update, Loggerhead viewer <br /> <br /> <br />
  • <br /> Clicking on &#x201C;view branch content&#x201D; <br /> <br />
  • Links to compare web-sites for each tool. <br /> Look at the differences and then some practical examples. <br />
  • <br /> <br />
  • Most specific at the bottom - Last one wins any conflict <br /> Tool level configuration - shell / IDE config later <br />
  • Mercurial Remotes - default for pulls, named remotes are possible but config editing is by hand. <br /> Bazaar - automatic after the first push, are named remotes possible? <br />
  • Mercurial - Only the hexnum is guaranteed unique -> Bazaar - Only the revision_id is guaranteed unique <br /> Advantages? <br /> Mercurial stores Changesets - what has changed / safer because it only ever appends data <br /> But fundamentally they all deal with patch files - groups of &#x201C;diff&#x201D;s - which are made up of &#x201C;hunks&#x201D;. <br /> <br /> <br />
  • <br />
  • History is immutable <br /> Standard is to clone the repo in a new directory <br /> Simple, intuitive, more like SVN, therefore less mistakes <br /> Apply a persistent name to a branch lets you do something Git like <br /> <br /> <br />
  • No clone of the repository in a new directory. <br /> A push does not oblige you to push all branches. <br /> Functionality is partially available in other systems with plugins, etc. <br />
  • Bound branch is like subversion but checks you&#x2019;re up to date with the central repository BEFORE making the local commit. <br /> Philosophy that the trunk should be ready to ship all the time <br />
  • CVS and SVN - &#x201C;time to branch&#x201D; is low, but merging itself is almost always a painful process. <br /> Merging a second time from another branch is WORSE. <br /> Incentives for developers to merge regularly are exactly the wrong way around. <br /> Tools need to track what has already been merged. <br />
  • Manage a stack of patches <br /> Can be put under version control <br /> Can be shared independently of the main repository <br />
  • <br />
  • <br />
  • <br />
  • Git is installed with .sample example scripts in .git/hooks <br /> Example use cases <br /> Arguments passed to scripts <br />
  • <br />
  • Murky only for OS X <br />
  • Netbean has support as well <br />
  • <br />
  • Jira searches for IDs in the repository (SVN plugin) BugTracker -> SCM <br /> Bugzilla - Bazaar / Mercurial / Git hooks update the bug IDs SCM -> BugTracker <br />
  • <br />
  • Capistrano - deployment runs on the target server - gets the code from the SCM system <br />
  • <br />
  • <br />
  • <br />
  • <br />

Transcript

  • 1. Distributed Source Code Management by Hugh Gilmour
  • 2. The closest a Scotsman is ever going to get to winning the World Cup.
  • 3. “Nobody actually creates perfect code the first time around, except me. But there's only one of me.” Linus Torvalds Tech Talk on Git “No revision control tool can rescue a poorly run project, but a good choice of tools can make a huge difference to the fluidity with which you can work on a project.” Bryan O’Sullivan Mercurial: The Definitive Guide
  • 4. Terminology Software configuration management (SCM) Source code management (SCM) Version control system (VCS) Revision control system (RCS)
  • 5. First Generation Single files on individual computers Restrictive locking model and reliance on a single computer Limited to small, tightly knit teams
  • 6. Second Generation Network-centered architectures for entire projects Server scaling problems as concurrent users increase Unreliable network connection means no repository, no information and no collaboration Read only access to a repository leaves you unable to record local changes
  • 7. Third Generation Peer to peer Distribution of revision control data to where it’s actually needed Operate offline indefinitely and autonomously Network only for syncing with another repository
  • 8. Distribute Metadata is stored locally in every copy Entire repository is on every contributor’s computer d Network reliability is not an issue Fideua
  • 9. SVN & Git http://gist.github.com/641268 svn checkout http://svn.symfony-project.com/branches/1.4 git clone git://github.com/symfony/symfony.git find ./1.4 -name ".svn" | wc -l find ./2/symfony -name ".git" | wc -l cd 1.4 echo "hello" >> README svn status; and_wait svn diff README; and_wait svn commit --non-interactive -m "impossible - network"; and_wait svn log --limit 1 README; and_wait svn revert README; and_wait cd - cd 2/symfony echo "hello" >> README git status; and_wait git diff README; and_wait git commit -a -m "possible without the network, added hello (again)"; and_wait git log -2 --date=relative README; and_wait cd -
  • 10. SVN & Git
  • 11. Demo Projects Parent project http://github.com/gilmation/dscm_project http://bitbucket.org/gilmation/hg_project http://bazaar.launchpad.net/~info-gilmation/+junk/bzr_project/files http://github.com/gilmation/git_project
  • 12. Project Structure http://bitbucket.org/gilmation/hg_project
  • 13. Comparing Tools… Mercurial Git Bazaar
  • 14. General 1 Repository Files Single .git, .hg, .bzr directories contain all information about a project Exclude Files .hgignore - Regular expressions unless you start the file with `syntax: glob` .gitignore - Standard glob patterns .bzrignore - No slash will match any filename anywhere in the tree Global ignores in ~/.bazaar/ignore The best way to get the content right is by trial and error.
  • 15. Configuration Mercurial hg help config man hgrc (to see the configuration options available) Manual creation of ~/.hgrc file hg showconfig (to check the file is ok) /etc/mercurial/hgrc /etc/mercurial/hgrc.d (any files that end in a .rc extension) ~/.hgrc $CURRENT_REPO/.hg/hgrc (propogated with the repository) Git git config --global user.name "Hugh Gilmour" git config --global user.email hugh@gilmation.com git config --list --system (/etc/gitconfig) --global (~/gitconfig) --file ($CURRENT_REPO/.git/config) Bazaar bzr explorer (for the gui) or at the command line: bzr whoami "Hugh Gilmour <hugh@gilmation.com>” bzr --version (should contain something like - Bazaar configuration: /Users/hgilmour/.bazaar) $HOME/.bazaar is created when you run `bzr whoami` for the first time and can contain: bazaar.conf (default config.) locations.conf (config. for specific branch locations) authentication.conf (credentials for remote servers) $CURRENT_REPO/.bzr/branch/branch.conf
  • 16. General 2 Commands Mercurial and Bazaar promote their commands as more similar in name and function to the commands of SVN than those of Git But all three have some “false friends” - To be sure read the docs ! All 3 tools allow commands to be “aliased” Adding Remotes Mercurial (by hand editing the file) $CURRENT_PROJECT/.hg/hgrc [paths] default = ssh://hg@bitbucket.org/gilmation/hg_project default-push = ssh://hg@bitbucket.org/gilmation/hg_project secondary = ssh://hg@bitbucket.org/gilmation/hg_project Git git remote add origin git@github.com:gilmation/git_project.git Bazaar (automatic) $CURRENT_REPO/.bzr/branch/branch.config push_location = bzr+ssh://bazaar.launchpad.net/~info-gilmation/%2Bjunk/bzr_project/ Directories Bazaar tracks directories as well as “content” In both Mercurial and Git to add an empty directory you have to fill it with a “dummy” file
  • 17. Revisions Mercurial is changeset based, uses num:hexnum Git is snapshot based, uses a 40 char SHA-1 hash to ID versions Bazaar is revision based, uses revision_number:revision_id
  • 18. Tags Mercurial hg tag $NAME hg tags Stored in $CURRENT_REPO/.hgtags (under version control - conflicts are possible) Two commits Git git tag git tag -a -m $NAME Tags can be lightweight or annotated (optionally signed with GNU Privacy Guard) Stored in .git/refs/tags Not pushed by default (use tagname or --tags) Bazaar bzr tag $NAME bzr tags Stored in .bzr/branch/tags
  • 19. Mercurial Branches Terminology is a bit messy! - Repository/Branch/Named Branch Standard behaviour is to isolate branches in repositories. Simplicity in the 1-to-1 relationship. Named branches allow multiple branches in a repository. These branches are always public/shared ! (clone/push/pull) lbranch Plugin allows local branches, makes them easy to delete
  • 20. Git Branches Git’s concept of branches are those that live in same directory. Local private branches or shared public branches. Moving from one branch to another is transparent. Use `git stash` to store temporary changes to change branches.
  • 21. Bazaar Branches Each branch in it’s own directory Lightweight checkout (no local repository) is like SVN Heavyweight checkout (synonym for a bound branch) Stand alone tree (via bzr init) Transparent foreign branches to SVN, Git and Mercurial.
  • 22. Merges All three tools are optimised for complex merges They track merge history and choose “best ancestor” for merging Renames (Add / Remove files) are tracked Directory modifications are tracked Octopus Merging is supported by Git and Mercurial (2+ Parent Revisions) Merge tools can be configured
  • 23. Mercurial Queues MQ Extension Configuration setup for queues: ~/.hgrc [extensions] hgext.mq = hg qinit .hg/patches hg qnew one.patch .hg/patches/one.patch .hg/patches/series .hg/patches/status hg qseries hg qapplied hg qpop hg qpush Patches with Guards + / - Guards hg qselect (to see activated Guards or activate Guard names) - Guards take preference
  • 24. Queue Options Rebase / Local Branches in Git - Similar but not the same Bazaar - Rebase plugin / Loom plugin / Quilt (without SCM)
  • 25. Git Commit The Git Index or Staging area 2 Step commit (using the staging area) git add --patch (allows you to be selective )
  • 26. Hooks / Extensions Mercurial Not under version control and do not propagate Defined in $HOME/.hgrc $PROJECT_HOME/.hg/hgrc Types Shell scripts “In-process” Python functions (complete access to the Mercurial API) Run locally with your permissions Over http or ssh outgoing hooks run on Server with Server’s permissions Controlling hooks determine if an activity can proceed (non-zero exit) Bundled Hooks acl, bugzilla, notify (email)
  • 27. Hooks / Extensions Git Not under version control and do not propagate Defined in $PROJECT_HOME/.git/hooks Any properly named executable scripts can be used Client-Side Hooks Committing-Workflow Hooks E-mail Workflow Hooks Other Client Hooks (pre-rebase, post-checkout, post-merge) Server-Side Hooks pre-recieve post-recieve update (once for every branch)
  • 28. Hooks / Extensions Bazaar Not under version control and do not propagate Defined in ~/.bazaar/plugins Hooks BranchHooks BzrDirHooks - repository initialized CommandHooks - allow commands to be extended InfoHooks - when displaying repository statistics MessageEditorHooks - when commit message is being generated MutableTreeHooks - before and after a commit Available plugins Email Feed generation Mirroring Tests (pqm, testrunner) Text (checkeol, text_checker)
  • 29. Native Tools Mercurial: TortoiseHG (Windows Explorer), Murky Git: gitk Bazaar: Bazaar Explorer, TortoiseBzr (Windows Explorer)
  • 30. Eclipse Git Git Support in Eclipse Helios EGit User Guide Mercurial HGE Project (1.5.1 Transition) Bazaar BzrEclipse Installation Doesn’t look very robust Trunk install of a plugin required
  • 31. Vim
  • 32. Bug Trackers Jira - CVS, SVN Trac - SVN Redmine - SVN, Mercurial, Git, Bazaar? Bugzilla - Mercurial, Bazaar, Git Launchpad Bugs (bugs.launchpad.net) - Bazaar Hooks / Extensions Debian Bugs (bugs.debian.org) - Bazaar Hooks / Extensions
  • 33. Repo Viewers Fisheye - Mercurial + Git Bazaar Loggerhead (https://launchpad.net/loggerhead) Social Coding Platforms
  • 34. Test & Deploy Hudson - Support for all three tools PhpUnderControl - CruiseControl support for all three Capistrano - deployment over ssh (Ruby)
  • 35. 29/09/10 - Bitbucket joins Atlassian
  • 36. Workflow Almost anything is possible. Simplest option is almost always the best. Work at the level of the least technical person on the project. Get a good mental model of how your chosen repository works. Central server or Gatekeeper models can be useful.
  • 37. Take aways Use a SCM system! Be disciplined, please! No Cargo Cults. Use the tool(s) that are the best fit for your context Centralised tools (SVN) are better for binary files (locks) Automate as much of your process as is practical Test (all the time)!
  • 38. THANK YOU TODAY’S TYPEFACES: CONTACT ME: Museo @shugster13 Museo Sans hugh@gilmation.com Flama