On 18/08/10 23:18, Bram Moolenaar wrote:
Tony Mechelynck wrote:
Problem: "default" branch has two heads, i.e. two changesets with have
no direct children _inside_ the same "default" branch (one of them is
the current 7.3 head, the other is the 7.2.446 changeset before the
creation of the "vim72" named branch). This causes problems for merging,
e.g. in a clone with local changes (I have two changed lines in
src/feature.h, in order to compile with -tag_old_static and +xterm_save).
Solution: Fold back the dead head into the trunk, as follows (assuming
that the repository is "updated" to the latest 7.3 patchlevel (currently
7.3.003)):
Why not update to 7.3?
Let's make sure there is no misunderstanding: I mean there has been an
hg update (or clone) to the "default" branch, but to that head of the
default branch which corresponds to the latest 7.3 changeset, not to the
7.2.446 changeset before defining the "vim72" branch. This is the normal
case; it is not the same as an update to the "vim73" branch.
hg --config ui.merge=internal:local merge
hg commit -m 'Fold old default branch back to trunk with
internal:local merge'
-- and in case my mailer or yours "prettified" the text, these are two
lines not three, and they both start with hg. The commit message can of
course be varied, I tried to make it both short and explicit, which is
not always easy.
The --config switch and argument are essential, they mean that whenever
there are differences between the two versions of a given file on the
two heads, we use the "local" one i.e. the version in the current
working directory.
Mercurial will ask:
remote changed README_lang.txt which local deleted
use (c)hanged version or leave (d)eleted?
Answer d followed by Enter.
The commit lists a lot of "merged" files but actually the contents of
the files are not modified, as can be checked afterwards with
hg diff -r 2a8bf2ba504f -r .
which shows no differences, meaning that no files have been added,
changed or removed between the two states of 7.3.003 "before" and
"after" the merge.
(There is a dot after the 2nd -r, meaning "current revision" i.e. the
result of the merge, and I didn't invent 2a8bf2ba504f, it's the
changeset ID for 7.3.003 "before the merge".)
You might ask: Why go to the trouble of creating a "phony" changeset
which changes nothing to the working directory yet lists 188 "modified"
files?
Answer: This way we establish which of the heads of the default branch
is the "real" one, which shall be used for further development on this
branch.
I would like to hear from a couple of people that this is the right way
to do this. Once this is committed and pushed it can't be undone!
OK.
Best regards,
Tony.
--
The more things change, the more they stay insane.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
