Mercurial - Distributed Version Controlling
•Descargar como PPTX, PDF•
0 recomendaciones•884 vistas
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.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Mercurial - Distributed Version Controlling
Similar a Mercurial - Distributed Version Controlling (20)
Último
Último (20)
Mercurial - Distributed Version Controlling
- 2. ”Version tools are not just important for maintaining a history of a project, they are also the foundation for a team to collaborate” - Martin Fowler http://martinfowler.com/bliki/VersionControlTools.html
- 3. Outline Bit Of History Centralized vs. Distributed DVCS repository structure and operation concepts Advantages over Centralized VCS Mercurial When it fails
- 4. History CVS(Concurrent Versioning System) started in 1986 On top of CVS –Subversion(2000) ,Perforce (1995) BitKeeper was the first truly DVCS Git, Mercurial ,Bazzar (2005) Currently in the field – Git , Mercurial
- 5. With Centralized VCS CI server
- 6. With Distributed VCS CI Server
- 9. With Distributed VCS Dinesh Buddhim a CI Server Ruwan Kapila
- 10. Structure and operation Local Remote Working Local Remote Director y Repo. repo. Hg add Hg Commit Hg Push Hg pull Hg Update Hg merge
- 11. Branching , Merging and Tagging Experimental, Feature branches Tagging is just giving a name to a changeset Local and global tagging Branch security and policies Merging – Change sets vs. Revisions
- 12. With Agile Teams
- 13. Workflows Flexibility of choosing your own workflow – Agile ? Policies witching team
- 14. Workflows
- 15. Workflows
- 16. Workflows
- 17. Other Advantages Renaming and Copying .SVN and .hg Folders Inbuilt web server space ?
- 18. Mercurial We chose Hg instead of Git, Bazzar Little slower than git Friendly for windows / Cross platform support- (TortoiseHg, Visual Hg) Similar syntax to SVN Lower maintenance and easier learning curve than Git Copying files supported
- 20. When It Fails Pessimistic locking Who has the latest revision ? Repository becomes publically available ?
- 22. References 1. http://www.infoq.com/articles/agile-version-control 2. http://martinfowler.com/bliki/VersionControlTools.html 3. http://www.joelonsoftware.com/items/2010/03/17.html 4. http://betterexplained.com/articles/intro-to-distributed- version-control-illustrated/ 5. http://progit.org/book/ch5-1.html 6. http://www.infoq.com/articles/agile-version-control
Notas del editor
- After the presentation of Linus in Google most of the people motivated to use DVCShttp://www.youtube.com/watch?v=4XpnKHJAok8
- You have a central server which everyone commit their changes
- Is it too complex..Everyone has their own repositoryEveryone can share changes with everyone is it good or bad?
- This is also possible. Buddhima has the central repository. Others push their changes to him and pull latest changes fomhim.. And buddhima is the one whoo can only push his changes to CI server. CI server can be another repository which maintains the releasable code.
- Share changes with others with out pushing to central. Local copies of the repository.
- Draw how change sets are organizedOther than push and pull all other basic operations are local.->FastUnique change set number for local and global change set id.The interesting part is that these systems think in terms of changes, not in terms of versions.That’s a very Zen-like thing to say, I know. Traditional version control thinks: OK, I have version 1. And now I have version 2. And now I have version 3.And distributed version control thinks, I had nothing. And then I got these changes. And then I got these other changes.Whereas if you free your mind and reimagine version control, and grok the zen of the difference between thinking about managing the versions vs. thinking about managing the changes, you’ll become enlightened and happy and realize that this is the way version control was meant to work.
- Branching\\tagging demonstration– branching example with bit bucket cargoSpotterBranch security with several teams and policies-will be in next slideDVCS encourages quick branching for experimentation. You can do branches in Subversion, but the fact that they are visible to all discourages people from opening up a branch for experimental work. Similarly a DVCS encourages check-pointing of work: committing incomplete changes, that may not even compile or pass tests, to your local repository. Again you could do this on a developer branch in Subversion, but the fact that such branches are in the shared space makes people less likely to do so4. When you manage changes instead of managing versions, merging works better, and therefore, you can branch any time your organizational goals require it, because merging back will be a piece of cake.With distributed version control, merges are easy and work fine. So you can actually have a stable branch and a development branch, or create long-lived branches for your QA team where they test things before deployment, or you can create short-lived branches to try out new ideas and see how they work.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 sothat 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 Ibet most people in the room probably have never created their own branch.Experimental branchesstructure is there to help you to find your "copies" back, no more. On the other side, branches and tags are well defined in mercurial. A tag is really a name that you put on a particular revision, and you can ask for all the existing tags. For branches, you'll see that there are MANY ways to handle them, but the one that fits best to the SVN philosophy, are named branches. http://stackoverflow.com/questions/2367453/recommended-mercurial-repository-folder-structure-for-an-svn-userLocal and global taging
- http://www.infoq.com/articles/agile-version-controlIf we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, releasable version at the end of each iteration? I didn't invent this scheme - it is based on the "mainline model" or "stable trunk pattern". See the references section for more info.Rule: Each branch (even the trunk) has an owner and a policy.Only create a new branch when you have something you want to check in, and there is no existing branch that you can use without violating its branch policy.This is because a centralized system provides you with an easy way to enforce your workflow, using a decentralized system requires more communication and discipline to stick to the established of conventions. While this may seem like it induces overhead, I see benefit in the increased communication necessary to make it a good process. Your team will need to communicate about code, about changes and about project status in general.
- Collaboration with peersThere are several models which defines how the project is maintained Eg:-Centralized with local commits - developers are making a series of changes, they do "commit --local" or unbind their checkout, then commit their work to the shared mainline when it is complete [6 ]Decentralized with shared mainline - Each developer has their own branch or branches, plus commit rights to the main branch. They do their work in their personal branch, then merge it into the mainline when it is ready. [6]Pull Only/Decentralized with Gatekeeper - Each developer has their own branch or branches. One developer (the gatekeeper) has commit rights to the main branch. When a developer wants their work merged, they ask the gatekeeper to merge it.[6 ] It is used when developing Linux Shared push - acts like a centralized system [7]One of the great things about DVCS is its adaptability to different ways of working.Workflows can be changed, mixed and matched as required. For example, a team may decide to use the traditional Centralized workflow but supplement it with Partner, i.e. two developers might exchange changes directly when working closely togethe
- Collaboration with peersThere are several models which defines how the project is maintained Eg:-Centralized with local commits - developers are making a series of changes, they do "commit --local" or unbind their checkout, then commit their work to the shared mainline when it is complete [6 ]Decentralized with shared mainline - Each developer has their own branch or branches, plus commit rights to the main branch. They do their work in their personal branch, then merge it into the mainline when it is ready. [6]Pull Only/Decentralized with Gatekeeper - Each developer has their own branch or branches. One developer (the gatekeeper) has commit rights to the main branch. When a developer wants their work merged, they ask the gatekeeper to merge it.[6 ] It is used when developing Linux Shared push - acts like a centralized system [7]One of the great things about DVCS is its adaptability to different ways of working.Workflows can be changed, mixed and matched as required. For example, a team may decide to use the traditional Centralized workflow but supplement it with Partner, i.e. two developers might exchange changes directly when working closely togethe
- http://wiki.netbeans.org/HgMigrationReasonssvn is nothing more than cvs
- Git- is pastest but complex not friendly to windows Bazzar-Made to be friendly, similar to SVN, slower of three
- http://martinfowler.com/bliki/VersionControlTools.html Git's advocates say that much of this is because it uses a different mental model to other VCSs, so you have to do more unlearn your knowledge of VCS to appreciate git.