Mercurial > hg-website
changeset 121:6ec2428ec891
moved concepts of hg for svn users to from-svn-to-hg.
| author | Arne Babenhauserheide <bab@draketo.de> |
|---|---|
| date | Tue, 28 Apr 2009 12:50:06 +0200 |
| parents | 17a30a75abaf |
| children | 76639683db9b |
| files | text/from-svn-to-hg.txt text/quick_start.txt |
| diffstat | 2 files changed, 98 insertions(+), 97 deletions(-) [+] |
line wrap: on
line diff
--- a/text/from-svn-to-hg.txt Fri Apr 24 21:35:50 2009 +0200 +++ b/text/from-svn-to-hg.txt Tue Apr 28 12:50:06 2009 +0200 @@ -2,3 +2,101 @@ * svn info -> hg paths * pull and push * svn up -r REV -> hg up REV + += Basic concepts of Mercurial for Subversion users = + +//If you're interested in the concepts behind Mercurial and already know Subversion, please join us and listen to a great explanation from Martin Geisler: // + +Let me try to make some of the basic concepts clear: + +* Like in Subversion, history consists of a number of commits. They're + called changesets in Mercurial. + +* Subversion requires a strict linear ordering of the commits and + gives nice linear revision numbers to them. So revision N has only + one child revision, rN+1. + + This is simple, but it requires a central server to make sure that + everybody agrees on the revision numbers. + +* Mercurial generalizes this by letting each changeset have multiple + children. If I work alone and make commits I'll make + + C1 --> C2 --> C3 + + by making three commits. The commit C3 with no children is a "head". + It is also the newest changeset in the repository -- called "tip". + + If I shared C1 with you and you started your work from that, your + commits will build a repository like this: + + C1 --> C2' --> C3' + + Here C3' is a head in your repository and I don't know anything + about C2' and C3' yet. + +* If I pull from you, or you push to me, the two repositories are + compared. By default, all missing changesets are transferred. This + is all there is to push/pull: compare two graphs of changesets and + transfer the missing ones. + + After a pull from you my repository will look like this: + + /-> C2 --> C3 + C1 -< + \-> C2' --> C3' + + Here C1 has two child changesets, and the repository has two heads + since the development has diverged. + + The changeset C3' will be the new tip since it is the newest + changeset in the repository. Note that tip is always a head, but a + head need not be the tip. + +* Having two heads suggest that someone should merge them -- otherwise + the changes from one will never be combined with the changes made in + the other head. + + When merging with 'hg merge' the task is to figure out the canonical + way to combine the changesets. If the changes do not overlap this is + usually trivial, otherwise you have to do a three-way merge. The + merge must be committed and this creates a changeset which explains + to the world how you think the two heads should be combined: + + /-> C2 --> C3 -\ + C1 -< >-> M + \-> C2' --> C3' -/ + + Note that the merge changeset M has two parents. + + If you do not merge C3 and C3' and try to push you get the 'new + remote head' message and push aborts. It aborts since it is a little + "impolite" to leave the job of merging to someone else -- he who + created the two heads by pulling in some code should also normally + do the merging. + + +> Sometimes it's hard to keep the several DVCS workings in my mind + + It helped me a lot to think in terms of the changeset graph. Remember +that: + + * "hg commit" adds a new node. The parent changesets of the new node + is given by "hg parents" + + * "hg push" and "hg pull" transfer nodes in the graph between two + repositories. + + * "hg update" updates the working copy to reflect a given node in + the history graph. This also changes the parent changeset of the + next commit, see "hg parents". + +> Is there not a simple Mercurial cheat sheet somewhere? + +There are some here: + +http://www.selenic.com/mercurial/wiki/index.cgi/QuickReferenceCardsAndCheatSheets + +- Martin Geisler + +PS: These descriptions were written on the [Mercurial mailinglist](http://selenic.com/mailman/listinfo/mercurial). \ No newline at end of file
--- a/text/quick_start.txt Fri Apr 24 21:35:50 2009 +0200 +++ b/text/quick_start.txt Tue Apr 28 12:50:06 2009 +0200 @@ -28,100 +28,3 @@ - Arne Babenhauserheide -= Basic concepts of Mercurial for Subversion users = - -//If you're interested in the concepts behind Mercurial and already know Subversion, please join us and listen to a great explanation from Martin Geisler: // - -Let me try to make some of the basic concepts clear: - -* Like in Subversion, history consists of a number of commits. They're - called changesets in Mercurial. - -* Subversion requires a strict linear ordering of the commits and - gives nice linear revision numbers to them. So revision N has only - one child revision, rN+1. - - This is simple, but it requires a central server to make sure that - everybody agrees on the revision numbers. - -* Mercurial generalizes this by letting each changeset have multiple - children. If I work alone and make commits I'll make - - C1 --> C2 --> C3 - - by making three commits. The commit C3 with no children is a "head". - It is also the newest changeset in the repository -- called "tip". - - If I shared C1 with you and you started your work from that, your - commits will build a repository like this: - - C1 --> C2' --> C3' - - Here C3' is a head in your repository and I don't know anything - about C2' and C3' yet. - -* If I pull from you, or you push to me, the two repositories are - compared. By default, all missing changesets are transferred. This - is all there is to push/pull: compare two graphs of changesets and - transfer the missing ones. - - After a pull from you my repository will look like this: - - /-> C2 --> C3 - C1 -< - \-> C2' --> C3' - - Here C1 has two child changesets, and the repository has two heads - since the development has diverged. - - The changeset C3' will be the new tip since it is the newest - changeset in the repository. Note that tip is always a head, but a - head need not be the tip. - -* Having two heads suggest that someone should merge them -- otherwise - the changes from one will never be combined with the changes made in - the other head. - - When merging with 'hg merge' the task is to figure out the canonical - way to combine the changesets. If the changes do not overlap this is - usually trivial, otherwise you have to do a three-way merge. The - merge must be committed and this creates a changeset which explains - to the world how you think the two heads should be combined: - - /-> C2 --> C3 -\ - C1 -< >-> M - \-> C2' --> C3' -/ - - Note that the merge changeset M has two parents. - - If you do not merge C3 and C3' and try to push you get the 'new - remote head' message and push aborts. It aborts since it is a little - "impolite" to leave the job of merging to someone else -- he who - created the two heads by pulling in some code should also normally - do the merging. - - -> Sometimes it's hard to keep the several DVCS workings in my mind - - It helped me a lot to think in terms of the changeset graph. Remember -that: - - * "hg commit" adds a new node. The parent changesets of the new node - is given by "hg parents" - - * "hg push" and "hg pull" transfer nodes in the graph between two - repositories. - - * "hg update" updates the working copy to reflect a given node in - the history graph. This also changes the parent changeset of the - next commit, see "hg parents". - -> Is there not a simple Mercurial cheat sheet somewhere? - -There are some here: - -http://www.selenic.com/mercurial/wiki/index.cgi/QuickReferenceCardsAndCheatSheets - -- Martin Geisler - -PS: These descriptions were written on the [Mercurial mailinglist](http://selenic.com/mailman/listinfo/mercurial). \ No newline at end of file