On Wed, Aug 18, 2010 at 2:01 PM, James Vega wrote:
> On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote:
>> I think what would normally happen is to merge the development branch
>> back into the default branch. But just like the problems you have now,
>> I suspect that migth not work very well.
>
> This would have worked just fine (as I had mentioned the first time it was
> brought up).
This is not quite right. Attempting to merge vim72 into default, or
default into vim72 (as with the following two sequences of commands)
requires to manually solve many merge conflicts.
# vim72 into default
hg clone vim-master foobar
cd foobar
hg merge vim72
# default into vim72
hg clone vim-master foobar
cd foobar
hg update vim72
hg merge default
> The expected way to resolve the end of a branch's development
> cycle is to merge it back into its parent. This would have prevented the
> problem that Tony raised about the default branch now having two heads.
Actually, having multiple heads in the same branch may be considered
as not a problem. When we have local changes, after pulling from the
official repository, in order to merge the new official changesets
into our own local changes, we now have to run (where <highest
revision number> is given by 'hg heads' for example):
hg merge -r <highest revision number>
instead of previously with only one head:
hg merge
Xavier
--
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
