Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Introduction to DVCSes with Mercurial
Similaire à Introduction to DVCSes with Mercurial (20)
Dernier
Dernier (20)
Introduction to DVCSes with Mercurial
- 1. Introduction to DVCSes with Mercurial Chris Velevitch Flash Platform Camp Wellington 04/09/2010
- 2. Why DVCSes?
- 6. Advantages of DVCS • scalable • faster • multiple backups • immune to network problems • forking non-problem • “Resistance Is Futile” • commerical projects
- 7. Why Mercurial? • Easy to learn • Light weight • Scales • Easy to customise
- 8. Who’s using Mercurial? • Growl - an open-source notifications system for Mac OS X • Linux HA - The High-Availability Linux Project • Mozilla • OpenJDK (a.k.a Java) • OpenOffice • Python (in progress) • Vim
- 9. Switching to Mercurial • ‘convert’ extension • Export to Subversion • Clients • command-line / http • TortoiseHG • MercurialEclipse • Windows, Mac OS X, Linux, Open SUSE, Solaris
- 10. Demo
- 11. Resources • mercurial.selenic.com • hginit.com • hge.javaforge.com/project/HGE • selenic.com/mailman/listinfo/mercurial
- 12. Thanks to all sponsors
Notes de l'éditeur
- Is there anyone here who doesn't know that version control systems automate the process of managing multiple versions of files?
- There are 3 main reasons for using a DVCS
- To prevent your code from being littered with the dried bones of in-progress features. Can be caused by undoing changes in the main branch because project priorities change
- To work offline with full access to the repository (including history, branches and tags).
- To better manage interruptions without impacting the quality of your work. If you’re working on a bug or a feature and you’ve been diligently checking in your progress, and then suddenly you need to fix another bug or the priorities have changed and now some other feature needs to be done first, what do you do with the work already done?
- ●scalable ○Mercurial’s high performance and peer-to-peer nature let you scale painlessly to handle large projects. ●faster ○no network latency ■all the metadata is stored locally ●multiple backups ○on each contributor's computer ●immune to network problems ●forking non-problem ○makes reconciliation easy ○every change is potentially a fork point ○the technical process of reconciliation is eliminated ○DVCS are really good at merging forks ●Resistance is futile ○there are tools that can pull your entire project's history and recreate it somewhere else ●commercial projects ○geographically dispersed teams ○multiple authoritative servers ■one per site
- ●convert extension ○Subversion ○CVS ○Git ○Darcs ●export to Subversion (ie hg is a svn client) ●open source converters ○vss2hg-1.03.pl & vss2hg-1.03.pl (note: I had problems with v1.04, but v1.03 worked for me)