SlideShare ist ein Scribd-Unternehmen logo
1 von 60
Downloaden Sie, um offline zu lesen
Distributed Source Control
      With Mercurial
Or, How I Learned to Stop Worrying and Love the Merge




       Ted Naleid - Lead Developer at Carol.com
Overview

•   Introduction
•   SVN (centralized VCS) vs DVCS
•   Current Popular DVCS Alternatives
•   Mercurial (hg) examples
•   Hands on with hg
checkout
                                           add
                                         remove
                                         update                          remote
                                           log                           central
                                         commit                           repos
                                          merge
                                            ...


                                                                                                       Build Server




                      Centralized VCS (SVN)
Everybody is relatively familiar with centralized version control systems.

SVN is only one of these, but others that are used quite a bit include CVS, Perforce, PVCS, and (ick!) ClearCase.

Centralized VCS systems have been around in one form or another for decades and have been relatively prevalent in business software development
for about the last 15 years.

In a centralized system, there is a server that people are granted access to. Any changes that you want to save, need to be checked in.
This server is the same server that continuous integration systems will pull from. The only way to get a change from Bob to Alice is to check it in so
that everyone gets the file (without going through patch files).

You can create branches for development, but those branches are full copies on the server that everyone has access to. It’s painful enough that I
bet most people in the room probably have never created their own branch.
Alice's
                                                                                 repos
                                                                  push
                              add                                  pull
                            remove
                            update                                      push                            Dave's
                              log                  Bob's                 pull                           repos
                            commit                 repos
                              diff
                                                                  push
                             merge
                                                                   pull
                               ...                                                 build
                                                                                  repos



                                                                                                     Build Server




              Distributed VCS (Mercurial)
In a distributed version control system, everyone has a full copy of the repository, this includes full history for each of the files.

Every repository is “equal”, though some repositories could be used in special ways (ex: the build machine’s repository).

As the diagram shows, it’s also easy for smaller teams to collaborate on changes in this model before pushing code to
designated repositories (like the build server’s repository). Bob can collaborate on code with Alice without having to affect either Dave or the build
server.

Bob is also able to add/remove code locally (thus saving state) without affecting anyone else. He’s also able to clone his repository to try out some
experimental work.

Since it’s all local, it’s just as quick and easy as copying a directory. If an experiment works, Bob can simply push that experimental code back into
his main
repository (or just switch over to the new one).
SVN Limitations



DVCS/Mercurial Strengths
Branching is easy, but
                     merging is painful


          Branching is easy, merging is
               (relatively) easy
Subversion’s merge isn’t history aware.
Users have to track which revisions have been merged between branches.
Like any manual process, this leads to mistakes/problems.

Merging is never completely painless, but the merge tools are much more aware of history

The tools also encourage frequent checking in as well as updating (since it’s easy to revert
state), so if you do run into a merge issue
it’s likely that you’ve got a small amount of code to merge rather than a huge “big bang”
update.
Active net connection
                   required to interact


          If your computer is on, you
          have access to the repository
Can’t do anything without a connection to the central repository, branch, diff, see the current
checked in version, etc.

Users are unable to save state if there are any issues with the repository, or if the build is
broken and they don’t want to “pile on” their changes into a broken build.
Unable to share changes
with others without sharing
      with everyone
       (including the build server)


   Sharing changes with
  selected people is easy
       (hg serve/hg push/hg pull)
Fails to merge changes when
            something is renamed


          Aware of file history and
         can merge into renamed file
If something gets renamed, the common method is to have everyone check any changes in
before you do the rename or else they manually need to move their changes over.
.svn files are littered
          throughout your source tree


           Single .hg directory at root
                  of source tree
This can make recursive grepping/searching easier as you don’t need to exclude all of
those .svn directories, just the root .hg dir.
Slow over-the-wire
                                     performance


                  Fast performance; you’re
                 working on local filesystem
As the repository continues to grow, this will become more and more of a problem.

This also enables activities and commands that aren’t possible in a client/server environment.

Mercurial has a “grep” command that lets you do a text search through your repository and it will show you the last revision that a piece of text
was there.

More and more tools are also appearing that are taking advantage of having all of this history info right on a local hard disk with some nice
visualization tools.
Discourages experimentation



         Cheap to create/throw away
          local experimental branch
Any branches in SVN are there forever and are visible to everyone (cluttering things up).

In a DVCS, it’s simple to clone your repository and give something else a try. If it works, you
can merge it in otherwise, you can throw it away.
SVN Strengths



DVCS/Mercurial
  Limitations
Familiar to most developers



          Most developers will need
          to learn to think differently
We’re all mac users here though, right? So we already know how to “think different” :)
Relatively easy to grasp


              Better understanding of
              version control concepts
                      required
Many developers don’t really even understand SVN all that well to begin with, just enough to
check code in/out.

I think that understanding version control is one of the core things that a developer should
be able to do.

As the old saw goes, “Those who cannot remember the past are condemned to repeat it”.
This is especially true when it comes to version control.
Everyone knows where the
          trunk is because there’s only
                    one server

           Need to define and adhere
            to convention to know
               where the trunk is
Without convention, things could spiral out of control with multiple forks of the source tree.

Not really that big of a deal in practice, just part of the mind switch and something people
need to think about.
Well established tool
                          support and integration


               Tool support and integration
                  isn’t quite as far along
Tool support is better than expected for Mercurial, integration with Eclipse and IntelliJ is complete (though I haven’t done much with either).

There is also much better potential for tools to get _really_ good as the entire VCS is local and any hits to it only impact you. You don’t need to
worry about expensive operations as much as you won’t be slowing everyone else down.
There is a winner among
                        free, centralized VCS
                          systems: Subversion

                 DVCS systems are still new
                 and a clear winner has not
                      been established
There have been 2 generations of DVCS systems. The first includes Arch and Monotone. First gen is generally considered slow and never really caught on in a
big way.

The second generation started with Darcs and the Bitkeeper debacle in the Linux core, and now has added Mercurial, Bazaar, and Git. There has been a lot of
buzz around these systems in the past couple of years. These are the systems that I’ll concentrate on.
Popular 2nd Gen DVCS
                      Systems
                                  Git - Bazaar - Mercurial




I’m covering the 3 “big” ones in 2008. These are all newer 2nd gen DVCS systems, there are
others like Arch, Monotone, BitKeeper, and Darcs that I’m not covering.

They all have smaller user bases, and I’m truthfully not that familiar with any of them.
Git
          Created by Linus Torvalds in 2005 after the BitKeeper “debacle”




BitKeeper was used for the linux kernel, but then they ended support for the Free Use version
of the software in early 2005.

There are many internet threads about this and most of the wikipedia page on BitKeeper
deals with this topic.
Git - Website & Hosting

•   Website: http://git.or.cz/
•   Hosting:
    •   http://github.com
    •   http://repo.or.cz
Git - Use in the Wild

•   Linux Kernel
•   One Laptop Per Child (OLPC)
•   Ruby on Rails
•   Lots of other Ruby stuff
•   Written mostly in C
Git - Common Wisdom
•   Fastest of the DVCS systems
•   Unfriendly to non-Linux/Unix systems
•   Complex, with ~150 commands added to path
•   Very popular in the Linux/Ruby communities
•   Probably the most “buzz” off all DVCS systems right
    now
Bazaar (bzr)
               Created by Canonical, Ltd. (creators of Ubuntu) in 2005




Started just slightly before the BitKeeper debacle.
Bazaar - Website & Hosting


•   Website: http://bazaar-vcs.org/
•   Hosting: https://launchpad.net/
Bazaar - Use in the Wild

•   Ubuntu
•   Drupal
•   Fairly big in Python community
    •   it’s written mostly in Python
Bazaar - Common Wisdom
                 •      Has gone through lots of revisions/changed formats
                 •      Slowest of the 3
                 •      Migration of an existing SVN repository is REALLY
                        slow
                 •      Made to be friendly, similar to SVN
                 •      Smallest market share


Supposedly, the speed of Bazaar has improved quite a bit and there were just some early revisions that gave it a bit of a bad name.

Not as slow as Darcs, Arch, Monotone, and some of the other less popular DVCS systems though.

Mozilla tried a migration from SVN and it took over a month of constant running for Bazaar to create the new repository.
Mercurial (hg)
Created by Matt Mackall in 2005 after the BitKeeper “debacle”
Mercurial - Website &
              Hosting
•   Website: http://www.selenic.com/mercurial/
•   Hosting:
    •   http://freehg.org/
    •   http://sharesource.org/
Mercurial - Use in the Wild
•   OpenJDK (Java)
•   OpenSolaris
•   Mozilla
•   NetBeans
•   Many others (largely Java/Python related)
    •   Like Bazaar, it’s mostly written in Python
Mercurial - Common Wisdom
 •   Similar syntax to SVN
 •   Slightly slower than Git, but faster than Bazaar
 •   Good cross-platform support
 •   Getting good support from large Java projects
     (OpenJDK, NetBeans, etc)
 •   Lower maintenance and easier learning curve than
     Git
Why did I choose
Mercurial over Git/Bazaar?
Similar commands to SVN
•   hg add
•   hg remove
•   hg update
•   hg log
•   hg status
•   It’s like SVN but with the ability to “push” and “pull”
Better cross platform support
          and growing tool integration


Plugins for IntelliJ and Eclipse.

Also TortiseHg for windows (similar to TortiseSvn)

Also has a plugin architecture that allows for extensions and other diff/merge programs to
be used.
No “packing” of the
                           repository is necessary


Git has a reputation for the size of the repository needing regular manual maintenance through “packing” and this has bit a number of new
developers.

The less manual things and maintenance a dev needs to perform, the better.
Local revision numbers are
                           “friendly”


In git, all you have to refer to are SHA-1 hashes.

Mercurial revision numbers aren’t perfect though, as it’s simply a local key to a real hash underneath the covers. Just like a database ID key, if you
look at another database, revision 14 is probably a different patch.
It’s used by a number of big
                   Java projects


OpenJDK, OpenSolaris, NetBeans
It’s the first one I tried :)
All 3 of these tools look
                       fantastic.


If any one of the 3 was the only thing available, I’d be happily using it and likely wouldn’t be
complaining.
Mercurial Usage Examples
        How do I do X?
portal/**                                     portal/.hg

                                          hg init
                     local                                          local
                      file             hg addremove
                                                                   repos
                    system              hg commit




                Create a new repository
inside any directory (example above “portal”), you can execute the commands shown to
create a local repository that you can check stuff into or that anyone else could potentially
clone or contribute to.
portal/**                         portal/.hg                       http://hg01/repos/portal


        local        creates tip files       local                                   remote
         file                                                  hg clone
                      on filesystem         repos                                     repos
       system
                                                      hg clone http://hg01/repos/portal




  “Checkout” an Existing Repository
The copy that you create has all of the history in the source repository.
portal/**                     portal/.hg             http://hg01/repos/portal

 local                                        hg pull
                                 local                       remote
  file
            hg update           repos                         repos
system

              quot;hg pull -uquot; will do this in one command




   Pull down the latest changes
                (no conflicts with local changes)
local file changes
                                       portal/.hg                         http://hg01/repos/portal
                  hg commit
                     conflict!                                   hg pull
     local      files unchanged!    hg update
                                                     local                        remote
      file                 hg merge                  repos                          repos
    system
                         hg commit
                                  quot;hg fetchquot; will pull->update->merge->commit in one command




         Pull down the latest changes
                        (conflicts detected with local changes)
“hg fetch” does all of that in one command, this just shows the details
local file changes
                                                                     portal/.hg                         http://hg01/repos/portal
                                       hg add
             local                    hg remove
                                    hg addremove                        local                                        remote
              file                                                                                                     repos
                                       hg commit                       repos
            system
                                                                                            hg push




 Push changes to another repository
                   (by default, push will refuse to run if it would require a merge)
If a push would increase the number of “heads”, this indicates that the one trying to do the push has forgotten to pull and merge changes before
pushing.

(Multiple heads means that there would be a conflict and 2 versions of an existing file at the same time, you can do an “hg heads” to see the
current list of heads)

This push will NOT update the files on the remote filesystem (which is a good thing). The remote repository would get the changes on the
filesystem at the next update.

This makes it possible for things like a build server not getting it’s files switched out from underneath it during a build if someone pushes
something new out.
http://hg01/repos/portal
portal/.hg

             hg incoming           remote
  local
                                    repos
 repos       hg outgoing




Do a push/pull dry run
portal/.hg


                                                         local
                      Branching is done by              repos
                   simply cloning a repository                            hg clone
                                                                   hg clone portal portal-clone
              portal-clone/**                      portal-clone/.hg

                  local         creates tip files         local
                   file           on filesystem           repos
                 system




                 Create a new “branch”
                           (experimenting is cheap and easy)

There is also an “hg branch” command to create what most people think of as a branch, but
this isn’t the recommended way of working for “big releases”. It’s easier and more obvious to
track clones of the repository, and you can also push/pull changes between local repositories
if you need to, so you aren’t losing anything.
local file changes
                                                                      portal/.hg

           local                         hg diff
            file                        hg status                          local
          system                       hg identify                       repos




Compare file system with repository
hg status and hg diff work very much like SVN
hg identify will show you the version of your working copy, you can compare this with “hg tip”
to see if it’s the same number and if you have the latest stuff in your repo in your working
copy on disk.
“hg identify -n” is useful as it shows you the local revision number of the working copy on the
file system
portal/.hg
                     hg log
                  hg annotate
                     hg cat                                     local
                    hg grep                                    repos
                   hg serve




             Query repository for info
There are many others if you dig in, but these are some of the basics.

“hg serve” starts up a web server that you can access at http://localhost:8000 by default
Hands on with Hg



Go through slides of what we’ll do and then do live-coding session in the terminal to show
details of each thing.
Creating new repository



create new grails project (using grails 1.0.3):
mkdir -p ~/temp && cd ~/temp
grails create-app HgTest
cd HgTest
grails create-domain-object Book
grails create-domain-object Author
mate .
// Edit files to this:
Author.groovy:                                    Book.groovy:                                BootStrap.groovy (inside def init):
class Author {                                    class Book {                                    def author = new Author(name:quot;Ray Bradburyquot;)

         String name                                  String title                               author.addToBooks(new Book(title: quot;Fahrenheit 451quot;))

         static hasMany = [books:Book]
                static belongsTo = [author: Author]       author.save()

         String toString() { name }                    String toString() { title }
}                                                 }

grails generate-all Book
grails generate-all Author
grails run-app
go to http://localhost:8080/HgTest/ and try out application
Now create repository with new code:
hg init
hg addremove
hg status
hg commit -m “initial checkin of HgTest”
hg serve // show files at http://localhost:8000
Cloning repository/
                                    branching


The easiest way to create a branch is done simply through cloning the repository. This is the recommended way to do “big picture” branches (such
as new revisions).

Open up new terminal window.
cd ~/temp
hg clone HgTest HgClone
cd HgClone
grails run-app // show that it works just like the old one does, Ray Bradbury is there
mate . ../HgTest
// edit BootStrap.groovy so that the book is Celsius 232.778
hg diff
hg commit -m “I’m feeling european today”
hg log

There is more normal “branch” support within a single repository, the HgBook refers to this as something more for “power users” and I agree that it
makes things less clear. Cloning repositories is easy, and it’s very clear based on the directory that you’re in which repo you’re working on.
Pushing changes to another
                         repository


// show hg log of HgTest, only one commit there
hg push
cd ../HgTest
hg tip // see commit message
// view file on disk, it hasn’t changed yet
hg update
// now it has

This is useful as you can push changes to a repository without messing up what it’s currently got in progress.
Once they do an update they’ll get the latest changes on the local filesystem (similar to checking into an SVN repo now).
Merging conflicting changes



// in HgTest
change author to “Theodore Sturgeon”
change book to “Microcosmic God”
hg commit -m “changing to short story”
hg log
show the log with #2 revision

cd ../HgClone
change author to “Daniel M. Pinkwater”
change book to “Lizard Music”
hg commit -m “dmp”

hg   pull
hg   heads
hg   update // conflict!
hg   merge
hg   commit -m “keeping microcosmic god”
hg   log // 2 parents to file
Creating a tag



hg tag foo
// tags are not copies like they are in subversion, they are simply revision aliases
hg log -r foo

hg tag -r 1 european
hg log -r european
hg tip

Tags are simply stored in a file in the root of the project called .hgtags
cat .hgtags

These tags will be pushed/pulled to any repository that you interact with. If you just want a marker for your own use, you can create a “local” tag:
hg tag -l my_local_tag
Searching through history



hg grep Bradbury
hg grep Pinkwater
Viewing repository through
                    a web browser


hg serve
// show 2 parents to merged file
A quick way to stick your toes in
            and try Mercurial out:
     use it as a “Super Client” for SVN


It’s nice to be able to very easily version filesets. Even if a company doesn’t switch to Mercurial, you can still use it locally to check stuff in before
grabbing new things from the server that you think could break you.

Then it’s easy to get back to your original state. I used this during a big grails upgrade.

Go into any directory that you’ve checked out of SVN.

hg   init
hg   addremove
hg   commit -m “initial checkin”
hg   serve // go to http://localhost:8000 to see the files you’ve checked in

now you can svn update without worry about getting back to your old state, you can also check in before trying something crazy out.

You now have a mercurial repository that you can check in to whenever you want (such as just before doing an update).

You can share it with others using “hg serve” to let them “hg clone” your repository.
Web Resources
•   Choosing a distributed version control system
          http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/

•   Understanding Mercurial
         http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial

•   Version Control and the “80%” (DVCS counterpoint)
         http://blog.red-bean.com/sussman/?p=79

•   Mercurial Book
         http://hgbook.red-bean.com/hgbook.html

•   Video of Bryan O’Sullivan (creator of the Mercurial Book)
         http://video.google.com/videoplay?docid=-7724296011317502612
Questions?

Weitere ähnliche Inhalte

Was ist angesagt?

Solving Real World Production Problems with Docker
Solving Real World Production Problems with DockerSolving Real World Production Problems with Docker
Solving Real World Production Problems with DockerMarc Campbell
 
Using Docker in the Real World
Using Docker in the Real WorldUsing Docker in the Real World
Using Docker in the Real WorldTim Haak
 
JavaOne 2016 - Pipeline as code
JavaOne 2016 - Pipeline as codeJavaOne 2016 - Pipeline as code
JavaOne 2016 - Pipeline as codeBert Jan Schrijver
 
7 Habits of Highly Effective Jenkins Users
7 Habits of Highly Effective Jenkins Users7 Habits of Highly Effective Jenkins Users
7 Habits of Highly Effective Jenkins UsersJules Pierre-Louis
 
Docker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing MeetupDocker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing MeetupJérôme Petazzoni
 
What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16
What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16 What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16
What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16 Docker, Inc.
 
Puppet and Vagrant in development
Puppet and Vagrant in developmentPuppet and Vagrant in development
Puppet and Vagrant in developmentAdam Culp
 
Continuous Integration using Docker & Jenkins
Continuous Integration using Docker & JenkinsContinuous Integration using Docker & Jenkins
Continuous Integration using Docker & JenkinsB1 Systems GmbH
 
How to Dockerize Web Application using Docker Compose
How to Dockerize Web Application using Docker ComposeHow to Dockerize Web Application using Docker Compose
How to Dockerize Web Application using Docker ComposeEvoke Technologies
 
Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)Jérôme Petazzoni
 
Learn docker in 90 minutes
Learn docker in 90 minutesLearn docker in 90 minutes
Learn docker in 90 minutesLarry Cai
 
Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015Jérôme Petazzoni
 
Pipeline as code - new feature in Jenkins 2
Pipeline as code - new feature in Jenkins 2Pipeline as code - new feature in Jenkins 2
Pipeline as code - new feature in Jenkins 2Michal Ziarnik
 
Let's go HTTPS-only! - More Than Buying a Certificate
Let's go HTTPS-only! - More Than Buying a CertificateLet's go HTTPS-only! - More Than Buying a Certificate
Let's go HTTPS-only! - More Than Buying a CertificateSteffen Gebert
 
Jenkins days workshop pipelines - Eric Long
Jenkins days workshop  pipelines - Eric LongJenkins days workshop  pipelines - Eric Long
Jenkins days workshop pipelines - Eric Longericlongtx
 
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...Lucas Jellema
 

Was ist angesagt? (20)

Solving Real World Production Problems with Docker
Solving Real World Production Problems with DockerSolving Real World Production Problems with Docker
Solving Real World Production Problems with Docker
 
Introduce to SVN
Introduce to SVNIntroduce to SVN
Introduce to SVN
 
Tech Talk - Vagrant
Tech Talk - VagrantTech Talk - Vagrant
Tech Talk - Vagrant
 
Using Docker in the Real World
Using Docker in the Real WorldUsing Docker in the Real World
Using Docker in the Real World
 
JavaOne 2016 - Pipeline as code
JavaOne 2016 - Pipeline as codeJavaOne 2016 - Pipeline as code
JavaOne 2016 - Pipeline as code
 
7 Habits of Highly Effective Jenkins Users
7 Habits of Highly Effective Jenkins Users7 Habits of Highly Effective Jenkins Users
7 Habits of Highly Effective Jenkins Users
 
Docker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing MeetupDocker Tips And Tricks at the Docker Beijing Meetup
Docker Tips And Tricks at the Docker Beijing Meetup
 
What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16
What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16 What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16
What's New in Docker 1.12 by Nishant Totla for Docker SF Meetup 08.03.16
 
Puppet and Vagrant in development
Puppet and Vagrant in developmentPuppet and Vagrant in development
Puppet and Vagrant in development
 
Continuous Integration using Docker & Jenkins
Continuous Integration using Docker & JenkinsContinuous Integration using Docker & Jenkins
Continuous Integration using Docker & Jenkins
 
How to Dockerize Web Application using Docker Compose
How to Dockerize Web Application using Docker ComposeHow to Dockerize Web Application using Docker Compose
How to Dockerize Web Application using Docker Compose
 
Jenkins Pipelines
Jenkins PipelinesJenkins Pipelines
Jenkins Pipelines
 
Docker
DockerDocker
Docker
 
Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)Microservices. Microservices everywhere! (At OSCON 2015)
Microservices. Microservices everywhere! (At OSCON 2015)
 
Learn docker in 90 minutes
Learn docker in 90 minutesLearn docker in 90 minutes
Learn docker in 90 minutes
 
Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015Containers: from development to production at DevNation 2015
Containers: from development to production at DevNation 2015
 
Pipeline as code - new feature in Jenkins 2
Pipeline as code - new feature in Jenkins 2Pipeline as code - new feature in Jenkins 2
Pipeline as code - new feature in Jenkins 2
 
Let's go HTTPS-only! - More Than Buying a Certificate
Let's go HTTPS-only! - More Than Buying a CertificateLet's go HTTPS-only! - More Than Buying a Certificate
Let's go HTTPS-only! - More Than Buying a Certificate
 
Jenkins days workshop pipelines - Eric Long
Jenkins days workshop  pipelines - Eric LongJenkins days workshop  pipelines - Eric Long
Jenkins days workshop pipelines - Eric Long
 
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...
 

Andere mochten auch

Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
Version Control Systems - ArabNet Beirut 2014 - Dani ArnaoutVersion Control Systems - ArabNet Beirut 2014 - Dani Arnaout
Version Control Systems - ArabNet Beirut 2014 - Dani ArnaoutDani Arnaout
 
An introduction to Version Control Systems
An introduction to Version Control SystemsAn introduction to Version Control Systems
An introduction to Version Control SystemsJon Warbrick
 
Intro To Version Control
Intro To Version ControlIntro To Version Control
Intro To Version Controlceardach
 
Introduction to Version Control System for Windows
Introduction to Version Control System for WindowsIntroduction to Version Control System for Windows
Introduction to Version Control System for WindowsPeter Chang
 
01 - Introduction to Version Control
01 - Introduction to Version Control01 - Introduction to Version Control
01 - Introduction to Version ControlSergii Shmarkatiuk
 
The everyday developer's guide to version control with Git
The everyday developer's guide to version control with GitThe everyday developer's guide to version control with Git
The everyday developer's guide to version control with GitE Carter
 
A brief introduction to version control systems
A brief introduction to version control systemsA brief introduction to version control systems
A brief introduction to version control systemsTim Staley
 
What is version control software and why do you need it?
What is version control software and why do you need it?What is version control software and why do you need it?
What is version control software and why do you need it?Leonid Mamchenkov
 
Version Control with SVN
Version Control with SVNVersion Control with SVN
Version Control with SVNPHPBelgium
 
Introduction to Version Control
Introduction to Version ControlIntroduction to Version Control
Introduction to Version ControlJeremy Coates
 

Andere mochten auch (11)

Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
Version Control Systems - ArabNet Beirut 2014 - Dani ArnaoutVersion Control Systems - ArabNet Beirut 2014 - Dani Arnaout
Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
 
An introduction to Version Control Systems
An introduction to Version Control SystemsAn introduction to Version Control Systems
An introduction to Version Control Systems
 
Intro To Version Control
Intro To Version ControlIntro To Version Control
Intro To Version Control
 
Introduction to Version Control System for Windows
Introduction to Version Control System for WindowsIntroduction to Version Control System for Windows
Introduction to Version Control System for Windows
 
01 - Introduction to Version Control
01 - Introduction to Version Control01 - Introduction to Version Control
01 - Introduction to Version Control
 
The everyday developer's guide to version control with Git
The everyday developer's guide to version control with GitThe everyday developer's guide to version control with Git
The everyday developer's guide to version control with Git
 
A brief introduction to version control systems
A brief introduction to version control systemsA brief introduction to version control systems
A brief introduction to version control systems
 
Intro to Git, GitHub, and BitBucket
Intro to Git, GitHub, and BitBucketIntro to Git, GitHub, and BitBucket
Intro to Git, GitHub, and BitBucket
 
What is version control software and why do you need it?
What is version control software and why do you need it?What is version control software and why do you need it?
What is version control software and why do you need it?
 
Version Control with SVN
Version Control with SVNVersion Control with SVN
Version Control with SVN
 
Introduction to Version Control
Introduction to Version ControlIntroduction to Version Control
Introduction to Version Control
 

Ähnlich wie Distributed Version Control (DVCS) With Mercurial

De-centralised Version Control with Bazaar
De-centralised Version Control with BazaarDe-centralised Version Control with Bazaar
De-centralised Version Control with BazaarStuart Colville
 
JavaEdge 2008: Your next version control system
JavaEdge 2008: Your next version control systemJavaEdge 2008: Your next version control system
JavaEdge 2008: Your next version control systemGilad Garon
 
Corwin on Containers
Corwin on ContainersCorwin on Containers
Corwin on ContainersCorwin Brown
 
Dev Environments: The Next Generation
Dev Environments: The Next GenerationDev Environments: The Next Generation
Dev Environments: The Next GenerationTravis Thieman
 
Jbossworld Presentation
Jbossworld PresentationJbossworld Presentation
Jbossworld PresentationDan Hinojosa
 
Version Uncontrolled - How to Manage Your Version Control (whitepaper)
Version Uncontrolled - How to Manage Your Version Control (whitepaper)Version Uncontrolled - How to Manage Your Version Control (whitepaper)
Version Uncontrolled - How to Manage Your Version Control (whitepaper)Revelation Technologies
 
Embracing Distributed Version Control
Embracing Distributed Version ControlEmbracing Distributed Version Control
Embracing Distributed Version ControlNowell Strite
 
SVN Usage & Best Practices
SVN Usage & Best PracticesSVN Usage & Best Practices
SVN Usage & Best PracticesAshraf Fouad
 
Git How Does That Work Then
Git How Does That Work ThenGit How Does That Work Then
Git How Does That Work ThenDavid Greaves
 
How to use CVS applied to SOLab
How to use CVS applied to SOLabHow to use CVS applied to SOLab
How to use CVS applied to SOLabPablo Arriazu
 
Why everyone is excited about Docker (and you should too...) - Carlo Bonamic...
Why everyone is excited about Docker (and you should too...) -  Carlo Bonamic...Why everyone is excited about Docker (and you should too...) -  Carlo Bonamic...
Why everyone is excited about Docker (and you should too...) - Carlo Bonamic...Codemotion
 
Virtualized development environments phpne - may 2012
Virtualized development environments   phpne - may 2012Virtualized development environments   phpne - may 2012
Virtualized development environments phpne - may 2012ichilton
 
codemotion-docker-2014
codemotion-docker-2014codemotion-docker-2014
codemotion-docker-2014Carlo Bonamico
 

Ähnlich wie Distributed Version Control (DVCS) With Mercurial (20)

De-centralised Version Control with Bazaar
De-centralised Version Control with BazaarDe-centralised Version Control with Bazaar
De-centralised Version Control with Bazaar
 
Cvs
CvsCvs
Cvs
 
JavaEdge 2008: Your next version control system
JavaEdge 2008: Your next version control systemJavaEdge 2008: Your next version control system
JavaEdge 2008: Your next version control system
 
Corwin on Containers
Corwin on ContainersCorwin on Containers
Corwin on Containers
 
Dev Environments: The Next Generation
Dev Environments: The Next GenerationDev Environments: The Next Generation
Dev Environments: The Next Generation
 
Jbossworld Presentation
Jbossworld PresentationJbossworld Presentation
Jbossworld Presentation
 
Version Uncontrolled - How to Manage Your Version Control (whitepaper)
Version Uncontrolled - How to Manage Your Version Control (whitepaper)Version Uncontrolled - How to Manage Your Version Control (whitepaper)
Version Uncontrolled - How to Manage Your Version Control (whitepaper)
 
Embracing Distributed Version Control
Embracing Distributed Version ControlEmbracing Distributed Version Control
Embracing Distributed Version Control
 
SVN Usage & Best Practices
SVN Usage & Best PracticesSVN Usage & Best Practices
SVN Usage & Best Practices
 
Git How Does That Work Then
Git How Does That Work ThenGit How Does That Work Then
Git How Does That Work Then
 
How to use CVS applied to SOLab
How to use CVS applied to SOLabHow to use CVS applied to SOLab
How to use CVS applied to SOLab
 
Svn Basic Tutorial
Svn Basic TutorialSvn Basic Tutorial
Svn Basic Tutorial
 
Building For Mer
Building For MerBuilding For Mer
Building For Mer
 
Docker In Brief
Docker In BriefDocker In Brief
Docker In Brief
 
Svn tutorial
Svn tutorialSvn tutorial
Svn tutorial
 
Svn tutorial
Svn tutorialSvn tutorial
Svn tutorial
 
Evolution ofversioncontrolinopensource
Evolution ofversioncontrolinopensourceEvolution ofversioncontrolinopensource
Evolution ofversioncontrolinopensource
 
Why everyone is excited about Docker (and you should too...) - Carlo Bonamic...
Why everyone is excited about Docker (and you should too...) -  Carlo Bonamic...Why everyone is excited about Docker (and you should too...) -  Carlo Bonamic...
Why everyone is excited about Docker (and you should too...) - Carlo Bonamic...
 
Virtualized development environments phpne - may 2012
Virtualized development environments   phpne - may 2012Virtualized development environments   phpne - may 2012
Virtualized development environments phpne - may 2012
 
codemotion-docker-2014
codemotion-docker-2014codemotion-docker-2014
codemotion-docker-2014
 

Kürzlich hochgeladen

AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 

Kürzlich hochgeladen (20)

AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 

Distributed Version Control (DVCS) With Mercurial

  • 1. Distributed Source Control With Mercurial Or, How I Learned to Stop Worrying and Love the Merge Ted Naleid - Lead Developer at Carol.com
  • 2. Overview • Introduction • SVN (centralized VCS) vs DVCS • Current Popular DVCS Alternatives • Mercurial (hg) examples • Hands on with hg
  • 3. checkout add remove update remote log central commit repos merge ... Build Server Centralized VCS (SVN) Everybody is relatively familiar with centralized version control systems. SVN is only one of these, but others that are used quite a bit include CVS, Perforce, PVCS, and (ick!) ClearCase. Centralized VCS systems have been around in one form or another for decades and have been relatively prevalent in business software development for about the last 15 years. In a centralized system, there is a server that people are granted access to. Any changes that you want to save, need to be checked in. This server is the same server that continuous integration systems will pull from. The only way to get a change from Bob to Alice is to check it in so that everyone gets the file (without going through patch files). You can create branches for development, but those branches are full copies on the server that everyone has access to. It’s painful enough that I bet most people in the room probably have never created their own branch.
  • 4. Alice's repos push add pull remove update push Dave's log Bob's pull repos commit repos diff push merge pull ... build repos Build Server Distributed VCS (Mercurial) In a distributed version control system, everyone has a full copy of the repository, this includes full history for each of the files. Every repository is “equal”, though some repositories could be used in special ways (ex: the build machine’s repository). As the diagram shows, it’s also easy for smaller teams to collaborate on changes in this model before pushing code to designated repositories (like the build server’s repository). Bob can collaborate on code with Alice without having to affect either Dave or the build server. Bob is also able to add/remove code locally (thus saving state) without affecting anyone else. He’s also able to clone his repository to try out some experimental work. Since it’s all local, it’s just as quick and easy as copying a directory. If an experiment works, Bob can simply push that experimental code back into his main repository (or just switch over to the new one).
  • 6. Branching is easy, but merging is painful Branching is easy, merging is (relatively) easy Subversion’s merge isn’t history aware. Users have to track which revisions have been merged between branches. Like any manual process, this leads to mistakes/problems. Merging is never completely painless, but the merge tools are much more aware of history The tools also encourage frequent checking in as well as updating (since it’s easy to revert state), so if you do run into a merge issue it’s likely that you’ve got a small amount of code to merge rather than a huge “big bang” update.
  • 7. Active net connection required to interact If your computer is on, you have access to the repository Can’t do anything without a connection to the central repository, branch, diff, see the current checked in version, etc. Users are unable to save state if there are any issues with the repository, or if the build is broken and they don’t want to “pile on” their changes into a broken build.
  • 8. Unable to share changes with others without sharing with everyone (including the build server) Sharing changes with selected people is easy (hg serve/hg push/hg pull)
  • 9. Fails to merge changes when something is renamed Aware of file history and can merge into renamed file If something gets renamed, the common method is to have everyone check any changes in before you do the rename or else they manually need to move their changes over.
  • 10. .svn files are littered throughout your source tree Single .hg directory at root of source tree This can make recursive grepping/searching easier as you don’t need to exclude all of those .svn directories, just the root .hg dir.
  • 11. Slow over-the-wire performance Fast performance; you’re working on local filesystem As the repository continues to grow, this will become more and more of a problem. This also enables activities and commands that aren’t possible in a client/server environment. Mercurial has a “grep” command that lets you do a text search through your repository and it will show you the last revision that a piece of text was there. More and more tools are also appearing that are taking advantage of having all of this history info right on a local hard disk with some nice visualization tools.
  • 12. Discourages experimentation Cheap to create/throw away local experimental branch Any branches in SVN are there forever and are visible to everyone (cluttering things up). In a DVCS, it’s simple to clone your repository and give something else a try. If it works, you can merge it in otherwise, you can throw it away.
  • 14. Familiar to most developers Most developers will need to learn to think differently We’re all mac users here though, right? So we already know how to “think different” :)
  • 15. Relatively easy to grasp Better understanding of version control concepts required Many developers don’t really even understand SVN all that well to begin with, just enough to check code in/out. I think that understanding version control is one of the core things that a developer should be able to do. As the old saw goes, “Those who cannot remember the past are condemned to repeat it”. This is especially true when it comes to version control.
  • 16. Everyone knows where the trunk is because there’s only one server Need to define and adhere to convention to know where the trunk is Without convention, things could spiral out of control with multiple forks of the source tree. Not really that big of a deal in practice, just part of the mind switch and something people need to think about.
  • 17. Well established tool support and integration Tool support and integration isn’t quite as far along Tool support is better than expected for Mercurial, integration with Eclipse and IntelliJ is complete (though I haven’t done much with either). There is also much better potential for tools to get _really_ good as the entire VCS is local and any hits to it only impact you. You don’t need to worry about expensive operations as much as you won’t be slowing everyone else down.
  • 18. There is a winner among free, centralized VCS systems: Subversion DVCS systems are still new and a clear winner has not been established There have been 2 generations of DVCS systems. The first includes Arch and Monotone. First gen is generally considered slow and never really caught on in a big way. The second generation started with Darcs and the Bitkeeper debacle in the Linux core, and now has added Mercurial, Bazaar, and Git. There has been a lot of buzz around these systems in the past couple of years. These are the systems that I’ll concentrate on.
  • 19. Popular 2nd Gen DVCS Systems Git - Bazaar - Mercurial I’m covering the 3 “big” ones in 2008. These are all newer 2nd gen DVCS systems, there are others like Arch, Monotone, BitKeeper, and Darcs that I’m not covering. They all have smaller user bases, and I’m truthfully not that familiar with any of them.
  • 20. Git Created by Linus Torvalds in 2005 after the BitKeeper “debacle” BitKeeper was used for the linux kernel, but then they ended support for the Free Use version of the software in early 2005. There are many internet threads about this and most of the wikipedia page on BitKeeper deals with this topic.
  • 21. Git - Website & Hosting • Website: http://git.or.cz/ • Hosting: • http://github.com • http://repo.or.cz
  • 22. Git - Use in the Wild • Linux Kernel • One Laptop Per Child (OLPC) • Ruby on Rails • Lots of other Ruby stuff • Written mostly in C
  • 23. Git - Common Wisdom • Fastest of the DVCS systems • Unfriendly to non-Linux/Unix systems • Complex, with ~150 commands added to path • Very popular in the Linux/Ruby communities • Probably the most “buzz” off all DVCS systems right now
  • 24. Bazaar (bzr) Created by Canonical, Ltd. (creators of Ubuntu) in 2005 Started just slightly before the BitKeeper debacle.
  • 25. Bazaar - Website & Hosting • Website: http://bazaar-vcs.org/ • Hosting: https://launchpad.net/
  • 26. Bazaar - Use in the Wild • Ubuntu • Drupal • Fairly big in Python community • it’s written mostly in Python
  • 27. Bazaar - Common Wisdom • Has gone through lots of revisions/changed formats • Slowest of the 3 • Migration of an existing SVN repository is REALLY slow • Made to be friendly, similar to SVN • Smallest market share Supposedly, the speed of Bazaar has improved quite a bit and there were just some early revisions that gave it a bit of a bad name. Not as slow as Darcs, Arch, Monotone, and some of the other less popular DVCS systems though. Mozilla tried a migration from SVN and it took over a month of constant running for Bazaar to create the new repository.
  • 28. Mercurial (hg) Created by Matt Mackall in 2005 after the BitKeeper “debacle”
  • 29. Mercurial - Website & Hosting • Website: http://www.selenic.com/mercurial/ • Hosting: • http://freehg.org/ • http://sharesource.org/
  • 30. Mercurial - Use in the Wild • OpenJDK (Java) • OpenSolaris • Mozilla • NetBeans • Many others (largely Java/Python related) • Like Bazaar, it’s mostly written in Python
  • 31. Mercurial - Common Wisdom • Similar syntax to SVN • Slightly slower than Git, but faster than Bazaar • Good cross-platform support • Getting good support from large Java projects (OpenJDK, NetBeans, etc) • Lower maintenance and easier learning curve than Git
  • 32. Why did I choose Mercurial over Git/Bazaar?
  • 33. Similar commands to SVN • hg add • hg remove • hg update • hg log • hg status • It’s like SVN but with the ability to “push” and “pull”
  • 34. Better cross platform support and growing tool integration Plugins for IntelliJ and Eclipse. Also TortiseHg for windows (similar to TortiseSvn) Also has a plugin architecture that allows for extensions and other diff/merge programs to be used.
  • 35. No “packing” of the repository is necessary Git has a reputation for the size of the repository needing regular manual maintenance through “packing” and this has bit a number of new developers. The less manual things and maintenance a dev needs to perform, the better.
  • 36. Local revision numbers are “friendly” In git, all you have to refer to are SHA-1 hashes. Mercurial revision numbers aren’t perfect though, as it’s simply a local key to a real hash underneath the covers. Just like a database ID key, if you look at another database, revision 14 is probably a different patch.
  • 37. It’s used by a number of big Java projects OpenJDK, OpenSolaris, NetBeans
  • 38. It’s the first one I tried :)
  • 39. All 3 of these tools look fantastic. If any one of the 3 was the only thing available, I’d be happily using it and likely wouldn’t be complaining.
  • 40. Mercurial Usage Examples How do I do X?
  • 41. portal/** portal/.hg hg init local local file hg addremove repos system hg commit Create a new repository inside any directory (example above “portal”), you can execute the commands shown to create a local repository that you can check stuff into or that anyone else could potentially clone or contribute to.
  • 42. portal/** portal/.hg http://hg01/repos/portal local creates tip files local remote file hg clone on filesystem repos repos system hg clone http://hg01/repos/portal “Checkout” an Existing Repository The copy that you create has all of the history in the source repository.
  • 43. portal/** portal/.hg http://hg01/repos/portal local hg pull local remote file hg update repos repos system quot;hg pull -uquot; will do this in one command Pull down the latest changes (no conflicts with local changes)
  • 44. local file changes portal/.hg http://hg01/repos/portal hg commit conflict! hg pull local files unchanged! hg update local remote file hg merge repos repos system hg commit quot;hg fetchquot; will pull->update->merge->commit in one command Pull down the latest changes (conflicts detected with local changes) “hg fetch” does all of that in one command, this just shows the details
  • 45. local file changes portal/.hg http://hg01/repos/portal hg add local hg remove hg addremove local remote file repos hg commit repos system hg push Push changes to another repository (by default, push will refuse to run if it would require a merge) If a push would increase the number of “heads”, this indicates that the one trying to do the push has forgotten to pull and merge changes before pushing. (Multiple heads means that there would be a conflict and 2 versions of an existing file at the same time, you can do an “hg heads” to see the current list of heads) This push will NOT update the files on the remote filesystem (which is a good thing). The remote repository would get the changes on the filesystem at the next update. This makes it possible for things like a build server not getting it’s files switched out from underneath it during a build if someone pushes something new out.
  • 46. http://hg01/repos/portal portal/.hg hg incoming remote local repos repos hg outgoing Do a push/pull dry run
  • 47. portal/.hg local Branching is done by repos simply cloning a repository hg clone hg clone portal portal-clone portal-clone/** portal-clone/.hg local creates tip files local file on filesystem repos system Create a new “branch” (experimenting is cheap and easy) There is also an “hg branch” command to create what most people think of as a branch, but this isn’t the recommended way of working for “big releases”. It’s easier and more obvious to track clones of the repository, and you can also push/pull changes between local repositories if you need to, so you aren’t losing anything.
  • 48. local file changes portal/.hg local hg diff file hg status local system hg identify repos Compare file system with repository hg status and hg diff work very much like SVN hg identify will show you the version of your working copy, you can compare this with “hg tip” to see if it’s the same number and if you have the latest stuff in your repo in your working copy on disk. “hg identify -n” is useful as it shows you the local revision number of the working copy on the file system
  • 49. portal/.hg hg log hg annotate hg cat local hg grep repos hg serve Query repository for info There are many others if you dig in, but these are some of the basics. “hg serve” starts up a web server that you can access at http://localhost:8000 by default
  • 50. Hands on with Hg Go through slides of what we’ll do and then do live-coding session in the terminal to show details of each thing.
  • 51. Creating new repository create new grails project (using grails 1.0.3): mkdir -p ~/temp && cd ~/temp grails create-app HgTest cd HgTest grails create-domain-object Book grails create-domain-object Author mate . // Edit files to this: Author.groovy: Book.groovy: BootStrap.groovy (inside def init): class Author { class Book { def author = new Author(name:quot;Ray Bradburyquot;) String name String title author.addToBooks(new Book(title: quot;Fahrenheit 451quot;)) static hasMany = [books:Book] static belongsTo = [author: Author] author.save() String toString() { name } String toString() { title } } } grails generate-all Book grails generate-all Author grails run-app go to http://localhost:8080/HgTest/ and try out application Now create repository with new code: hg init hg addremove hg status hg commit -m “initial checkin of HgTest” hg serve // show files at http://localhost:8000
  • 52. Cloning repository/ branching The easiest way to create a branch is done simply through cloning the repository. This is the recommended way to do “big picture” branches (such as new revisions). Open up new terminal window. cd ~/temp hg clone HgTest HgClone cd HgClone grails run-app // show that it works just like the old one does, Ray Bradbury is there mate . ../HgTest // edit BootStrap.groovy so that the book is Celsius 232.778 hg diff hg commit -m “I’m feeling european today” hg log There is more normal “branch” support within a single repository, the HgBook refers to this as something more for “power users” and I agree that it makes things less clear. Cloning repositories is easy, and it’s very clear based on the directory that you’re in which repo you’re working on.
  • 53. Pushing changes to another repository // show hg log of HgTest, only one commit there hg push cd ../HgTest hg tip // see commit message // view file on disk, it hasn’t changed yet hg update // now it has This is useful as you can push changes to a repository without messing up what it’s currently got in progress. Once they do an update they’ll get the latest changes on the local filesystem (similar to checking into an SVN repo now).
  • 54. Merging conflicting changes // in HgTest change author to “Theodore Sturgeon” change book to “Microcosmic God” hg commit -m “changing to short story” hg log show the log with #2 revision cd ../HgClone change author to “Daniel M. Pinkwater” change book to “Lizard Music” hg commit -m “dmp” hg pull hg heads hg update // conflict! hg merge hg commit -m “keeping microcosmic god” hg log // 2 parents to file
  • 55. Creating a tag hg tag foo // tags are not copies like they are in subversion, they are simply revision aliases hg log -r foo hg tag -r 1 european hg log -r european hg tip Tags are simply stored in a file in the root of the project called .hgtags cat .hgtags These tags will be pushed/pulled to any repository that you interact with. If you just want a marker for your own use, you can create a “local” tag: hg tag -l my_local_tag
  • 56. Searching through history hg grep Bradbury hg grep Pinkwater
  • 57. Viewing repository through a web browser hg serve // show 2 parents to merged file
  • 58. A quick way to stick your toes in and try Mercurial out: use it as a “Super Client” for SVN It’s nice to be able to very easily version filesets. Even if a company doesn’t switch to Mercurial, you can still use it locally to check stuff in before grabbing new things from the server that you think could break you. Then it’s easy to get back to your original state. I used this during a big grails upgrade. Go into any directory that you’ve checked out of SVN. hg init hg addremove hg commit -m “initial checkin” hg serve // go to http://localhost:8000 to see the files you’ve checked in now you can svn update without worry about getting back to your old state, you can also check in before trying something crazy out. You now have a mercurial repository that you can check in to whenever you want (such as just before doing an update). You can share it with others using “hg serve” to let them “hg clone” your repository.
  • 59. Web Resources • Choosing a distributed version control system http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ • Understanding Mercurial http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial • Version Control and the “80%” (DVCS counterpoint) http://blog.red-bean.com/sussman/?p=79 • Mercurial Book http://hgbook.red-bean.com/hgbook.html • Video of Bryan O’Sullivan (creator of the Mercurial Book) http://video.google.com/videoplay?docid=-7724296011317502612