hg import -exact) then you may need to explictly specify the rebase options. Rebase is usually automatic in the common case where the divergence has been caused by pulling from the master, but if they’ve occurred for another reason (e.g. The "-continue" means that any conflicts will be resolved in your working copy, which will then need committing. However if you’ve already got the divergence in your repository, you can rebase specifically: hg rebase -continue You can do this during the pull by appending the -rebase command (or selecting it in TortoiseHg): hg pull -rebase Instead, by using the Rebase extension, after pulling someone elses changes you rebase your own commits so that they are re-applied on top of the head you pulled from the master, essentially flattening the history and looking like there was never any deviation, like this: Because this is literally an everyday occurrence of short-term deviation, this is extremely distracting when trying to decipher the history, and therefore not recommended. The HG Init tutorials suggest resolving this by merging the changes with your own (covered next), which is indeed the standard no-extension way to handle this, but it has one major drawback - every time it happens, in the history you have a permanent record of this divergence in the form of a split and merge of the 2 developers changes.
The most common case of deviations like this is simple, short-term parallel development within the team (for more long-term deviations, see the next section).
REBASE TORTOISEHG PATCH
Or, maybe the orange revisions came from a patch applied as "hg import -exact", or pulling changes from a fork. This situation could have been caused by making your own changes (green), and pulling someone elses changes from the master (orange) which were based on the same ancestor. This may occur because you have pulled changesets into your repository when you have other changes of your own on that branch, or that you’ve created deviating paths locally (which you can do by manually updating to a previous revision, then committing from that point, creating a split in the branch:
It’s actually possible in Mercurial to have more than one "HEAD" revision on a single branch in one repository, although by default you’re not allowed to push that ambiguitiy to anyone else.
Mercurial lets everyone commit locally, so committed deviations can build up in the distributed repositories, and have to be resolved differently. In centralised systems like Subversion, the only way to record a commit is at the master repository, so all parallel development must be resolved into one stream (per branch) at commit time. 2.5.1. Deviations in development within a branch
0 kommentar(er)
