Your SlideShare is downloading. ×
0
© 2010 Shivercube
© 2010 Shivercube
 Clone an existing repository to create a new
local repository for development
 Each developer must ha...
© 2010 Shivercube
 Atomic collection of changes to files in a
repository
 Uniquely identified with a changeset ID
 In a...
© 2010 Shivercube
 The creation of a new changeset
 Each commit should have a description
 Each commit should have a si...
© 2010 Shivercube
 Diverged line of development
 Linear sequence of consecutive changesets
 Default branch name is “def...
© 2010 Shivercube
 Symbolic identifier for a changeset
 Use to mark different versions of the system
 Most recent chang...
© 2010 Shivercube
 Push changes to another repository
 Adds changes in local repository to the
remote repository
 Only ...
© 2010 Shivercube
 Pull changes from another repository
 Retrieves changesets from a remote
repository and merges them i...
© 2010 Shivercube
© 2010 Shivercube
 Allows two different strands of development
at the same time
 Quick and easy to switch between branch...
© 2010 Shivercube
 Create two copies of a repository
 Transfer changesets between them as often as
you want
 Safe way t...
© 2010 Shivercube
© 2010 Shivercube
 Create new branches for new features
 Able to merge changes between branches
 Permanently adds chang...
© 2010 Shivercube
© 2010 Shivercube
 Fastest and easiest way to implement small
changes
 Update to any revision and commit
 Use changeset...
© 2010 Shivercube
© 2010 Shivercube
 Combines two separate changesets into a
merge changeset
 Joins points of two branches into one
 Usua...
Upcoming SlideShare
Loading in...5
×

Team development with mercurial

2,892

Published on

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • regarrding slide 10, when it says 'default branch should always contain ...'
    Are you sure about this?
    That seems quite in contrast with respect to the official Hg/Mercurial suggested way, here:

    http://mercurial.selenic.com/wiki/StandardBranching

    Specifically:

    ***
    3. The default branch

    This is where development of new features occurs [...].
    (!) It is strongly recommended to do your primary development on the so-called 'default' branch, because it is the branch used by default in various commands such as clone.
    ***
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total Views
2,892
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Team development with mercurial"

  1. 1. © 2010 Shivercube
  2. 2. © 2010 Shivercube  Clone an existing repository to create a new local repository for development  Each developer must have their own local copy before making any changes  Makes a copy of a repository at a point in time  Checks out the tip of the default branch
  3. 3. © 2010 Shivercube  Atomic collection of changes to files in a repository  Uniquely identified with a changeset ID  In a single repository identified by a revision number
  4. 4. © 2010 Shivercube  The creation of a new changeset  Each commit should have a description  Each commit should have a single specific purpose  Bulk amount of work should be separated into individual commits  Don’t do too much in a single commit
  5. 5. © 2010 Shivercube  Diverged line of development  Linear sequence of consecutive changesets  Default branch name is “default”  Supports naming
  6. 6. © 2010 Shivercube  Symbolic identifier for a changeset  Use to mark different versions of the system  Most recent changeset called “tip”
  7. 7. © 2010 Shivercube  Push changes to another repository  Adds changes in local repository to the remote repository  Only adds changes which are missing in the remote repository
  8. 8. © 2010 Shivercube  Pull changes from another repository  Retrieves changesets from a remote repository and merges them into the local repository  Only transfers changesets which are missing in the local repository
  9. 9. © 2010 Shivercube
  10. 10. © 2010 Shivercube  Allows two different strands of development at the same time  Quick and easy to switch between branches  “default” branch should always contain production code  Always contains the latest workable version of the system  Code being developed should be under separate branches
  11. 11. © 2010 Shivercube  Create two copies of a repository  Transfer changesets between them as often as you want  Safe way to create branches  Repositories are completely isolated until you push or pull  Can’t break something in one branch while working in another  Easy to delete branch  Good for single developer testing features, but not good for developers working as a team
  12. 12. © 2010 Shivercube
  13. 13. © 2010 Shivercube  Create new branches for new features  Able to merge changes between branches  Permanently adds changeset metadata  Close branches after finished
  14. 14. © 2010 Shivercube
  15. 15. © 2010 Shivercube  Fastest and easiest way to implement small changes  Update to any revision and commit  Use changeset IDs to switch back and forth  Won’t be any descriptive name for a branch  Best for simple changes or experiments by a single developer
  16. 16. © 2010 Shivercube
  17. 17. © 2010 Shivercube  Combines two separate changesets into a merge changeset  Joins points of two branches into one  Usually collisions can be automatically handled  Can use KDiff3 to intelligently merge changes into a single file
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×