Introduction to Distributed Version Control System with Mercurial / TortoiseHgEng Chin Gan
This is a presentation that I made for Experian Tech Talk in August 2012. It covers basic introduction to DVCS using Mercurial / TortoiseHg as example.
A presentation on distributed version controlling with Mercurial. starts with some introduction on the concept of distributed version controlling and then guidance tp choose best version controlling system out of available tools.
Docker and Containers for Development and Deployment — SCALE12XJérôme Petazzoni
Docker is an Open Source engine to build, run, and manage containers. We'll explain what are Linux Containers, what powers them (under the hood), and what extra value Docker brings to the table. Then we'll see what the typical Docker workflow looks like from a developer point of view. We'll also give an Ops perspective, including deployment options. If you already saw a "Docker 101", consider this presentation as the February 2014 update! :-)
Introduction to Distributed Version Control System with Mercurial / TortoiseHgEng Chin Gan
This is a presentation that I made for Experian Tech Talk in August 2012. It covers basic introduction to DVCS using Mercurial / TortoiseHg as example.
A presentation on distributed version controlling with Mercurial. starts with some introduction on the concept of distributed version controlling and then guidance tp choose best version controlling system out of available tools.
Docker and Containers for Development and Deployment — SCALE12XJérôme Petazzoni
Docker is an Open Source engine to build, run, and manage containers. We'll explain what are Linux Containers, what powers them (under the hood), and what extra value Docker brings to the table. Then we'll see what the typical Docker workflow looks like from a developer point of view. We'll also give an Ops perspective, including deployment options. If you already saw a "Docker 101", consider this presentation as the February 2014 update! :-)
Entwicklungsteams stehen heutzutage unter enormen Zeitdruck, da gilt: "In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish" (Klaus Schwab, Founder and Executive Chairman of the World Economic Forum). Weiterhin muss Software gegen Testsysteme entwickelt und getestet werden, die soweit wie möglich an Produktionssysteme angelehnt sind, um Aussagen wie "Runs on my machine" endgültig abzuwürgen. Aufgrund des Zeitdrucks müssen diese Testsysteme sehr schnell aufgesetzt und auch wieder zerstört werden können. Vagrant versucht diese Probleme zu lösen, indem es vorhandene Virtualisierungs- und Provisionierungs-Tools orchestriert und damit Entwicklern die Möglichkeit bietet Testsysteme lokal und in "self-service" zu verwalten. Dieser TechTalk soll Entwicklern eine Einführung in die Konzepte und Benutzung von Vagrant geben.
Looking at how people, with current deployments, can start using docker with out having to replace anything. Also giving a migration path that allows testing the separate pieces and migrating over slowly without painting yourself into a corner. Also covering why you might want to do this and the problems it may help to solve.
Docker Tips And Tricks at the Docker Beijing MeetupJérôme Petazzoni
This talk was presented in October at the Docker Beijing Meetup, in the VMware offices.
It presents some of the latest features of Docker, discusses orchestration possibilities with Docker, then gives a briefing about the performance of containers; and finally shows how to use volumes to decouple components in your applications.
Enhancing the application development process in all its phases—building, scaling, shipping, deploying
and running—plays a vital role in today’s competitive IT industry by shortening the time between writing
code and running it.
Containers: from development to production at DevNation 2015Jérôme Petazzoni
In Docker, applications are shipped using a lightweight format, managed with a high-level API, and run within software containers which abstract the host environment. Operating details like distributions, versions, and network setup no longer matter to the application developer.
Thanks to this abstraction level, we can use the same container across all steps of the life cycle of an application, from development to production. This eliminates problems stemming from discrepancies between those environments.
Even so, these environments will always have different requirements. If our quality assurance (QA) and production systems use different logging systems, how can we still ship the same container to both? How can we satisfy the backup and security requirements of our production stack without bloating our development stack?
In this sess, you will learn about the unique features in containers that allow you to cleanly decouple system administrator tasks from the core of your application. We’ll show you how this decoupling results in smaller, simpler containers, and gives you more flexibility when building, managing, and evolving your application stacks.
Pipeline as code - new feature in Jenkins 2Michal Ziarnik
What is pipeline as code in continuous delivery/continuous deployment environment.
How to set up Multibranch pipeline to fully benefit from pipeline features.
Jenkins master-node concept in Kubernetes cluster.
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...Lucas Jellema
Creating and managing environments for development and R&D activities can be cumbersome. Quickly spinning up databases and web servers, using physical resources in a smart way, installing application components, and having all the elements talk to each other can take a lot of time. This session takes you by the hand and introduces you to Vagrant and Oracle VM VirtualBox for quickly provisioning VMs in which Docker containers run platform components, applications, and microservices—all set up by use of Puppet and interacting with Git(Hub). You’ll start from zero on your laptop and end with both local and public cloud environments in which to develop, test, and run various types of applications. Lean governance and evolution of the environments are discussed too.
Version Control Systems - ArabNet Beirut 2014 - Dani ArnaoutDani Arnaout
This is the presentation that was given at ArabNet Beirut 2014. It cover some basic & intermediate info about Version Control Systems in a simple & special way.
It includes lots of images & just few text, so you won't be able to fully understand what's going on unless you watched the talk.
Will add a link to the talk once it becomes available.
Entwicklungsteams stehen heutzutage unter enormen Zeitdruck, da gilt: "In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish" (Klaus Schwab, Founder and Executive Chairman of the World Economic Forum). Weiterhin muss Software gegen Testsysteme entwickelt und getestet werden, die soweit wie möglich an Produktionssysteme angelehnt sind, um Aussagen wie "Runs on my machine" endgültig abzuwürgen. Aufgrund des Zeitdrucks müssen diese Testsysteme sehr schnell aufgesetzt und auch wieder zerstört werden können. Vagrant versucht diese Probleme zu lösen, indem es vorhandene Virtualisierungs- und Provisionierungs-Tools orchestriert und damit Entwicklern die Möglichkeit bietet Testsysteme lokal und in "self-service" zu verwalten. Dieser TechTalk soll Entwicklern eine Einführung in die Konzepte und Benutzung von Vagrant geben.
Looking at how people, with current deployments, can start using docker with out having to replace anything. Also giving a migration path that allows testing the separate pieces and migrating over slowly without painting yourself into a corner. Also covering why you might want to do this and the problems it may help to solve.
Docker Tips And Tricks at the Docker Beijing MeetupJérôme Petazzoni
This talk was presented in October at the Docker Beijing Meetup, in the VMware offices.
It presents some of the latest features of Docker, discusses orchestration possibilities with Docker, then gives a briefing about the performance of containers; and finally shows how to use volumes to decouple components in your applications.
Enhancing the application development process in all its phases—building, scaling, shipping, deploying
and running—plays a vital role in today’s competitive IT industry by shortening the time between writing
code and running it.
Containers: from development to production at DevNation 2015Jérôme Petazzoni
In Docker, applications are shipped using a lightweight format, managed with a high-level API, and run within software containers which abstract the host environment. Operating details like distributions, versions, and network setup no longer matter to the application developer.
Thanks to this abstraction level, we can use the same container across all steps of the life cycle of an application, from development to production. This eliminates problems stemming from discrepancies between those environments.
Even so, these environments will always have different requirements. If our quality assurance (QA) and production systems use different logging systems, how can we still ship the same container to both? How can we satisfy the backup and security requirements of our production stack without bloating our development stack?
In this sess, you will learn about the unique features in containers that allow you to cleanly decouple system administrator tasks from the core of your application. We’ll show you how this decoupling results in smaller, simpler containers, and gives you more flexibility when building, managing, and evolving your application stacks.
Pipeline as code - new feature in Jenkins 2Michal Ziarnik
What is pipeline as code in continuous delivery/continuous deployment environment.
How to set up Multibranch pipeline to fully benefit from pipeline features.
Jenkins master-node concept in Kubernetes cluster.
Java Developer Intro to Environment Management with Vagrant, Puppet, and Dock...Lucas Jellema
Creating and managing environments for development and R&D activities can be cumbersome. Quickly spinning up databases and web servers, using physical resources in a smart way, installing application components, and having all the elements talk to each other can take a lot of time. This session takes you by the hand and introduces you to Vagrant and Oracle VM VirtualBox for quickly provisioning VMs in which Docker containers run platform components, applications, and microservices—all set up by use of Puppet and interacting with Git(Hub). You’ll start from zero on your laptop and end with both local and public cloud environments in which to develop, test, and run various types of applications. Lean governance and evolution of the environments are discussed too.
Version Control Systems - ArabNet Beirut 2014 - Dani ArnaoutDani Arnaout
This is the presentation that was given at ArabNet Beirut 2014. It cover some basic & intermediate info about Version Control Systems in a simple & special way.
It includes lots of images & just few text, so you won't be able to fully understand what's going on unless you watched the talk.
Will add a link to the talk once it becomes available.
Provides an absolute beginner\'s guide to how version control works, why you should switch and how to get started. Note that this presentation was for Design 4 Drupal, so it is angled towards Drupal themers.
A brief introduction to version control systemsTim Staley
This is a lunchtime talk I gave to the Southampton astronomy department. The aim was to make them aware of version control systems and when they might need to use them.
With these slides we introduce the concept of source control and teach the core features to using Git, GitHub and BitBucket. You can find the accompanying video here. https://youtu.be/lZpNrCgGvuI
JavaEdge 2008: Your next version control systemGilad Garon
The next generation of VCS has a clear target ahead of them: making branching and merging easier. Until recently, Subversion was dominating the world of Version Control Systems, but now, Distributed Version Control Systems are growing in popularity and everywhere you go you hear about Git or Mercurial, and how they make branching and merging a breeze. But the Subversion team isn't going down quietly, they have a new weapon: the 1.5 version. Learn about the next generation of Version Control Systems is planning to solve your problems.
This was a talk given internally at BloomReach as well as a guest lecture to a grad level Data Structures and Algorithms class at the University of Texas at Arlington.
A Deep dive on the history of containers, and how they work under the cover utilizing Linux Kernel features such as Process Namespaces and Control Groups.
I also go over a bit of the history of Container technology, going from Chroot and Jails and Zones, to LXC and Docker
Development environments are a necessary part of every developer's workflow. They can also be a great source of friction. What may begin as simply running python my_app.py eventually bloats as you add more apps, more databases, more testing frameworks, and more developers. We'll talk about the evolution of a typical development environment, how it lets us down, and how we try to make it better. We'll end with an introduction to Dusty, a new tool which uses Docker containers to take our development environments to the next level.
Originally presented at PyGotham 2015.
Explain a little about git and how we use it in Mer and Maemo.
Please note that there are notes for these slides (click the 'Notes' link/tab by the 'Comments' tab below)
I made a simple SVN (Subversion) tutorial for my co-workers and just wanted to share it with you. It is based on other lectures and practical experience I had in the past.
Some ideas also come from the GIT world, which is still too far and new for everyone, but which I already love and embrace fully :)
Since Fremantle Extras applications will eventually be submitted to the Mer builder it may be a good idea to introduce it.
We use the openSuse Open Build Service; a GPL service that provides an emulated, pristine (yes, I'm looking at you autobuilder and scratchbox), dependency driven build environment.
I'll talk about the processes around Mer builds, access controls, managing integration with our DVCS (git), acceleration tricks and generally how to make good use of things you find lying about on the web.
This slideset has useful notes - see tab next to 'Comments'
Why everyone is excited about Docker (and you should too...) - Carlo Bonamic...Codemotion
In less than two years Docker went from first line of code to major Open Source project with contributions from all the big names in IT. Everyone is excited, but what's in for me - as a Dev or Ops? In short, Docker makes creating Development, Test and even Production environments an order of magnitude simpler, faster and completely portable across both local and cloud infrastructure. We will start from Docker main concepts: how to create a Linux Container from base images, run your application in it, and version your runtimes as you would with source code, and finish with a concrete example.
Virtualized development environments phpne - may 2012ichilton
A talk at PHP North East, 12th May 2012 - introduction to Virtualization, Vagrant, Configuration Management / Infrastructure as Code, Puppet and Chef...
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
By Design, not by Accident - Agile Venture Bolzano 2024
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.
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.
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.
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
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
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.
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
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