Revision control with Mercurial
•Télécharger en tant que PPTX, PDF•
0 j'aime•1,373 vues
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Revision control with Mercurial
Similaire à Revision control with Mercurial (20)
Plus de Paulo Gandra de Sousa
Dernier
Dernier (20)
Revision control with Mercurial
- 1. Revision Control with Mercurial Paulo Gandra de Sousa @pagsousa
- 2. • The need • Basic concepts • Distributed revision control • Best practices • Tools Agenda
- 3. • Share and synchronize among team members • Fast and reliable undo • For errors • For previous released versions • Track changes • Connect with task & bug management • Sandboxing The need
- 4. • Repository • Trunk • Add • Check in • Revision • Diff • Head Basic concepts http://betterexplained.com/articles/a-visual-guide-to-version-control/
- 5. • Check out • Working copy • Revert • Check in Basic edit flow http://betterexplained.com/articles/a-visual-guide-to-version-control/
- 6. • Diff • Merge • Resolve Handling conflits http://betterexplained.com/articles/a-visual-guide-to-version-control/
- 7. • Add • Delete • Rename • Forget • Lock • To avoid Handling files
- 8. • Each user owns a repository and serve it to other users • May use central (by convention) repository Distributed version control http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
- 9. Geographicaly distributed teams http://www.ericsink.com/vcbe/vcbe_a4_lo.pdf
- 10. Merge head changeset Head; tip Revisions, heads, tips
- 11. • Each user clones a “central” repository or inits a local repository • Joel edits and/or adds files, check status, and commits in his local repository http://hginit.com/02.html
- 12. • Joel pushes his push change set to another (e.g., the “central”) repository • Rose pulls from the central repository pull http://hginit.com/02.html
- 13. • Joel and Rose edit and commit in their local repository • Rose pushes to the central repository http://hginit.com/02.html
- 14. • Joel trys to push but pull gets an error • Joel pulls the changes • Joel merges the two heads and resolves any conflict • Joel commits and pushes to the central repository http://hginit.com/02.html
- 15. • Pull changes/Update before editing • Commit often • One commit – one issue • Write meaningful commit messages • Don’t commit broken code • Review the merge before commit • Setup change notifications • Read Diffs from other developers Best practices
- 16. TOOLS Mercurial, TortoiseHG, HGE, Netbeans
- 17. • Download • http://mercurial.selenic.com/wiki/Download • Tutorial • http://mercurial.selenic.com/wiki/Tutorial • Hg definitive guide • http://hgbook.red-bean.com/ • Hosting (free and comercial) • http://mercurial.selenic.com/wiki/MercurialHosting Mercurial
- 18. • Download • http://tortoisehg.bitbucket.org/download/ • Quick tutorial • http://tortoisehg.bitbucket.org/manual/1.1/quick.html • TortoiseHg Manual • http://tortoisehg.bitbucket.org/manual/2.3/ TortoiseHg
- 19. • Clone • Init Shell extension menu
- 20. • Commit • Status • Add • Revert • Remove • Update • Synchronize Shell extension menu
- 21. Hg Workbench
- 22. • Download • http://javaforge.com/project/HGE HGE (Eclipse plugin)
- 23. New project
- 26. Commit
- 27. Compare
- 28. History
- 29. • Download • http://netbeans.org/downloads/ • Netbean’s Mercurial User Guide • http://netbeans.org/kb/docs/ide/mercurial.html Netbeans
- 30. Clone repository
- 31. Context
- 32. History
- 33. Commit
- 34. Push
- 35. • A visual guide to version control, http://betterexplained.com/articles/a-visual-guide-to-version-control/ • Joel Spolsky, Hg Init, http://hginit.com/ • Distributed version control illustrated, http://betterexplained.com/articles/intro-to-distributed-version- control-illustrated/ • Eric Sink, Version Control by example. http://www.ericsink.com/vcbe/vcbe_a4_lo.pdf • Tutorial, http://mercurial.selenic.com/wiki/Tutorial • Understanding Mercurial, http://mercurial.selenic.com/wiki/UnderstandingMercurial • Version control 10 best practices, http://blog.manishchhabra.com/2011/04/10-version-control-best- practices/ Bibliography
Notes de l'éditeur
- http://betterexplained.com/articles/a-visual-guide-to-version-control/Large, fast-changing projects with many authors need a Version Control System (geekspeak for “file database”) to track changes and avoid general chaos. A good VCSdoes the following:Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.Synchronization. Lets people share files and stay up-to-date with the latest version.Short-term undo. Monkeying with a file and messed it up? (That’s just like you, isn’t it?). Throw away your changes and go back to the “last known good” version in the database.Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day.Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for blamestorming giving credit.Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before “checking in” your changes.Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.
- http://betterexplained.com/articles/a-visual-guide-to-version-control/Repository (repo): The database storing the files.Trunk/Main: The primary location for code in the repo. Think of code as a family tree — the trunk is the main line.Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.Check in: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.Revision: What version a file is on (v1, v2, v3, etc.).Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.Head: The latest revision in the repo.
- http://betterexplained.com/articles/a-visual-guide-to-version-control/Check out: Download a file from the repo.Working Set/Working Copy: Your local directory of files, where you make changes.Revert: Throw away your local changes and reload the latest version from the repository.
- http://betterexplained.com/articles/a-visual-guide-to-version-control/Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another. Conflict: When pending changes to a file contradict each other (both changes cannot be applied).Resolve: Fixing the changes that contradict each other and checking in the correct version.
- Use thetooloptions for adding a file to revisioncontrolDon’tdelet files thruthefilesystem -> use thetool to remove the file fromrevisioncontrolSame thing for renamesYou can alsoinstructthe SCMtool to forgetbout some files, i.e., do notincludethem in revisioncontrolanddon’taskagain to includeornotTrynot to use Lockatall!
- Distributedrepositories – eachuserowns a “local” copyoftherepositoryUsers can pull/pushchangesfrom/to anyrepository“central” repositorybyconventiononlyHg serve - Mercurial has a built-in light-weight web server which can be used for browsing a repository with a web browser or for allowing remote machines to pull from you.
- Easilyhandlegeographicaldistributionof teamsConsider a development team that is split up in two cities. Half the team is in a satellite office in CrabappleCove, Maine, and the other half is at the company’s headquarters in Ottumwa, Iowa. With a CVCS, theyhave to pick one city to hold the central server and everybody in the other city has to access it over an Internetlink. With a DVCS (as shown in Figure 5.1), they can set up a central server in each city and use push andpull to synchronize them whenever as they want.
- http://mercurial.selenic.com/wiki/UnderstandingMercurialMercurial groups related changes to multiple files into single atomic changesets, which are revisions of the whole project. These each get a sequential revision number. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. So Mercurial also assigns each revision a global changeset ID. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487".Branches and merges in the revision history can occur at any point. Each unmerged branch creates a new head of the revision history. Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the tip of the repository, the head with the highest revision number. Revision 4 is a merge changeset, as it has two parent changesets (revisions 2 and 3).
- Clone – create a new local repositorybasedon a copyofanotherexsitingrepositoryInit – create a new local repositorywithemptycontentsAdd – add files to versioncontrol (pendingchanges)Status – show pendingchangesCommit – commitpendingchanges. Creates a newchange set in thehistoryoftherepository
- Push – sendchange set Pull
- AllwaysworkwiththelatestcodeversionShort andfrequentcommitsHandlejustoneissue per commitMakesurethecode compiles and runs (and passes testsifyouhavethen) beforecommitingAfterdoing a mergemakesureyoureviewitandrunalltestsagainbeforecommitingCheckwhatothershavecommited to keepupwiththeprojectcode base
- Createprojectfromexistingsourcesiftherepo does notcontain a NB project
- “Team” menu onmain menu bar