On Saturday 21 August 2010 11:48:23 Tony Mechelynck wrote:
> On 18/08/10 14:49, Xavier de Gaye wrote:
> > 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
> Also, with multiple heads in the current branch, the "fetch"
> extension cannot be used: instead of one command
> hg fetch --switch-parent
> you have to run three
> hg pull -u
> hg merge -r ab3fc5de6b49
> hg commit -m 'merge for patchlevel 7.3.004'
> and the text for the latter two (or at least for the middle
> one) varies every time.
i've got a bash script that's been working for me for several
days now to simplify the merge -- i call it 'cs' and i think
"changeset" when i use it:
#!/bin/bash
# changeset
cd ~/.build/hgvim/vim
hg heads | awk -f ../lft.awk
where lft.awk contains:
# look for tip
/^changeset/ { cs = $0 }
/tag: tip/ {
split(cs, csa, /:/)
csn = csa[2]
gsub(/ /, "", csn)
print csn
}
then to merge i can type
u2 `cs`
where u2 contains:
#!/bin/bash
# u2
cd ~/.build/hgvim/vim
date '+%Y-%b-%d %H:%M' 2>&1 | tee -a ../update.log
echo "about to hg merge $@" >> ../update.log
hg merge $@ 2>&1 | tee -a ../update.log
dsh | tee -a ../update.log
(and dsh just makes dashes)
i had to modify 'cs' recently when the wanted changeset no
longer contained both the tip and vim73 tags, and it may
change again soon, but this is working for me now and avoids
copying those horrible changeset ids (actually uses the
4-digit local prefix to the full id, which merge is fine with)
this is all so new and evolving i still like to run heads and
'cs' to verify it is naming the changeset i deem relevant
before i attempt using it to merge, and i recommend anyone
else using it do the same, at least until things settle down
and get a little more predictable
sc
--
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
