Mercurial simple example [duplicate]

StackOverflow https://stackoverflow.com/questions/7887578

  •  11-02-2021
  •  | 
  •  

Question

Possible Duplicate:
Introduction to Mercurial

My most recent change is remote. Did I finally do this right?

$ hg pull
warning: code.google.com certificate with fingerprint d2:33:75:af:62:64:5b:75:dc:3f:bf:22:30:b6:27:13:ff:3f:90:fd not verified (check hostfingerprints or web.cacerts config setting)
pulling from https://niklasro@code.google.com/p/montao/
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
ubuntu@ubuntu:/media/Lexar/montao$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

So I shouldn't do merge, I should do pull?

Why is there no simple example how 2 developers collaborate?

For example

Time        Developer 1              Developer  2
              hg clone                 hg clone
              editing
              hg commit
              hg push
                                       editing
                                       hg pull
                                       hg commit
                                       hg push

An example of workflow between 2 developers like above would make it much easier to understand what's hg pull, merg, update and not make me confuse pull with merge.

For example how I now know how to not get 2 heads when there is a changeset from another place.

I could need an example how 2 developers collaborate and how I get remote changes.

Was it helpful?

Solution

For great in-depth examples of how to use Mercurial and a few other VCS's check out Eric Sink's Version Control by Example or Joel Spolsky's hginit.com (Does my answer get an automatic downvote for listing Joel second?)

OTHER TIPS

Basic concepts

Pull brings new changesets from other developers into your own repository. This can potentially introduce a new head, it will say so if it does.

Merge combines two heads into one. You don’t need to merge if there isn’t more than 1 head.

Update switches between revisions, e.g. from your current working revision to one you just pulled in. If you have local un-committed changes, update will try to combine them by performing an untracked merge.

Whether you update or merge after a pull depends on whether the pull introduced new heads.

Simple two-developer workflow

The simplest basic workflow when directly cooperating between two developers is:

  1. hg pull otherdev
  2. hg update or hg merge
  3. Edit
  4. hg commit -m "testing..."

The pull + update (shorthand: pull -u) makes sure you are starting out on the most recent version of the code. If your colleague made any changes between your last pull and commit, this will tell you it introduced a new head and you need to merge instead.

You don’t always have to pull, you can also skip it sometimes and just edit, commit, edit, commit (...) for a while; if you’re working on something and don’t want to disrupt your flow, just wait with pulling and merging until you are ready (but I would do it at least once a day).

In general you shouldn’t push changes to your colleague; this way you each stay in control of what is in your repository, and you won’t get confused by new changesets suddenly appearing.

Note: By updating between step 3 and 4 you reduce the likelihood of creating a diverging branch, in SVN this is something that you are forced to do. However I would recommend against this practice, because if there are conflicts it will leave your changes in a broken state and you won’t be able to commit it until you fix it. One of the big advantages of a DVCS is exactly that you can avoid this and safely commit your working code before having to bother with merging.

Improved two-developer workflow

To improve this workflow, I would actually recommend to create a third, shared repo for you and your colleague to use as an intermediate, instead of directly pulling from eachother.

This introduces an additional push step, but the nice thing about this is that you can make a bunch of commits and decide by yourself when your changes are ready to share with your colleague, by pushing. This reduces time needed for testing and the odds of wasting your colleague’s time because you accidentally broke something and he pulled it in.

If you type hg help pull

It shows:

pull changes from the specified source

    Pull changes from a remote repository to a local one.

So it is RemoteRepository->Local Repository operation. nothing to do with your local working directory.

If you type 'hg help merge'

merge working directory with another revision

    The current working directory is updated with all changes made in the requested revision since the last common predecessor revision.

It happens between your local repository and your local working copy. nothing to do with remote repo.

If you asked for examples/manuals, there are a lot on the net. i list some here, hope itis helpful for you.

http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://www.rutherfurd.net/2010/apr/22/merging-mercurial-example/
https://www.mercurial-scm.org/wiki/TutorialMerge

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top