Plans for Mercurial branches?
björn
I was wondering what the plans for the Mercurial branches are once 7.3
is finished. Will "vim73" be merged into "default" at some point, or
will there be one giant "vim73 patch" applied to "default" (making all
changesets in the "vim73" branch into a patch) and "vim73" will be
left, or ...?
I am wondering because I am in the process of changing the MacVim repo
to use the Vim Mercurial repo as upstream instead of the svn repo.
This is to allow me to make an informed decision as to which branch to
merge my own "macvim" branch against.
Thanks,
Björn
--
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
Bram Moolenaar
Björn Winckler wrote:
> I was wondering what the plans for the Mercurial branches are once 7.3
> is finished. Will "vim73" be merged into "default" at some point, or
> will there be one giant "vim73 patch" applied to "default" (making all
> changesets in the "vim73" branch into a patch) and "vim73" will be
> left, or ...?
>
> I am wondering because I am in the process of changing the MacVim repo
> to use the Vim Mercurial repo as upstream instead of the svn repo.
> This is to allow me to make an informed decision as to which branch to
> merge my own "macvim" branch against.
done I don't know. There were some problems when I used "hg rebase" on
the vim73 branch, now it's no longer possible to merge directly from the
default branch into the vim73 branch. I don't know if the other way
around would still work. Or that we need to use export + import.
--
From "know your smileys":
...---... SOS
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
björn
>
> Björn Winckler wrote:
>
>> I was wondering what the plans for the Mercurial branches are once 7.3
>> is finished. Will "vim73" be merged into "default" at some point, or
>> will there be one giant "vim73 patch" applied to "default" (making all
>> changesets in the "vim73" branch into a patch) and "vim73" will be
>> left, or ...?
>>
>> I am wondering because I am in the process of changing the MacVim repo
>> to use the Vim Mercurial repo as upstream instead of the svn repo.
>> This is to allow me to make an informed decision as to which branch to
>> merge my own "macvim" branch against.
>
> When 7.3 is released it will become the default branch. How this is
> done I don't know. There were some problems when I used "hg rebase" on
> the vim73 branch, now it's no longer possible to merge directly from the
> default branch into the vim73 branch. I don't know if the other way
> around would still work. Or that we need to use export + import.
have to rewrite history in some way (e.g. export+import).
On that topic, will the history of the "default" branch never be
rewritten (no rebase, etc.)? If so, I will merge the MacVim branch
against the default branch (and probably keep a topic branch that
merges against vim73).
Björn
Tony Mechelynck
> On 23 May 2010 12:38, Bram Moolenaar wrote:
>>
>> Björn Winckler wrote:
>>
>>> I was wondering what the plans for the Mercurial branches are once 7.3
>>> is finished. Will "vim73" be merged into "default" at some point, or
>>> will there be one giant "vim73 patch" applied to "default" (making all
>>> changesets in the "vim73" branch into a patch) and "vim73" will be
>>> left, or ...?
>>>
>>> I am wondering because I am in the process of changing the MacVim repo
>>> to use the Vim Mercurial repo as upstream instead of the svn repo.
>>> This is to allow me to make an informed decision as to which branch to
>>> merge my own "macvim" branch against.
>>
>> When 7.3 is released it will become the default branch. How this is
>> done I don't know. There were some problems when I used "hg rebase" on
>> the vim73 branch, now it's no longer possible to merge directly from the
>> default branch into the vim73 branch. I don't know if the other way
>> around would still work. Or that we need to use export + import.
>
> I don't know how to do this either -- from what I can tell you will
> have to rewrite history in some way (e.g. export+import).
>
> On that topic, will the history of the "default" branch never be
> rewritten (no rebase, etc.)? If so, I will merge the MacVim branch
> against the default branch (and probably keep a topic branch that
> merges against vim73).
>
> Björn
>
default branch always be the branch undergoing active development, i.e.,
usually not the current stable branch but the experimental branch which
will someday become the next release. Then when work starts on a further
release, the current release is branched off, and the work-in-progress
for the new release happens on the "default" without affecting the
stable release which has just received a branch name. OTOH the
branched-off release(s) may still receive security & stability updates
for some time (usually at a decreasing rate) and then die (be "closed"
in Mercurial language).
Mercurial is based on invariant history, so in principle (with a few
exceptions such as hg rollback) what has been done cannot be undone, and
too bad for the (l)user if he goofed and doesn't see it at once.
If we someday want that what is now the default branch become a "vim72"
branch while the current vim73 branch should become a new "default", it
may be quite hard to achieve. Maybe with the transplant extension and/or
the experimental hg rebase --detach (available only in the development
version of the rebase extension)... Now if only there were a few more
examples and explanations in that Mercurial documentation...
Maybe it will be simpler to go on with the vim73 branch, and someday let
the so-called default branch die, when Vim 7.2 will be at EOL?
Or else, maybe (but I don't know if it's allowed) "hg branch -f default"
to "force" the current (vim73) branch to become the default, obscuring
the earlier default? Maybe after "hg branch vim72" on the current
default, so that work on Vim 7.2 can still continue?
Best regards,
Tony.
--
Prostitution is the only business where you can go into the hole and
still come out ahead.
Xavier de Gaye
>
> ...
>
The 'vim73' branch can be given the name of the 'default' branch with
the 'hg branch --force default' command after the 'default' branch is
named 'vim72' with the 'hg branch vim72' command (both followed by
commit).
A simple test made on a fake repo with 'default' and 'vim73' branches
(same as in the current vim repo) shows this result after that is done:
$ hg branches
default 5:ce5266650699
vim72 4:d5bb6abbab9a
vim73 3:90078dbe59dd (inactive)
Changeset '3:90078dbe59dd' is the tip of the vim73 branch before it is
renamed to 'default'.
Xavier
Bram Moolenaar
Björn Winckler wrote:
> On 23 May 2010 12:38, Bram Moolenaar wrote:
> >
> > Björn Winckler wrote:
> >
> >> I was wondering what the plans for the Mercurial branches are once 7.3
> >> is finished. Will "vim73" be merged into "default" at some point, or
> >> will there be one giant "vim73 patch" applied to "default" (making all
> >> changesets in the "vim73" branch into a patch) and "vim73" will be
> >> left, or ...?
> >>
> >> I am wondering because I am in the process of changing the MacVim repo
> >> to use the Vim Mercurial repo as upstream instead of the svn repo.
> >> This is to allow me to make an informed decision as to which branch to
> >> merge my own "macvim" branch against.
> >
> > When 7.3 is released it will become the default branch. How this is
> > done I don't know. There were some problems when I used "hg rebase" on
> > the vim73 branch, now it's no longer possible to merge directly from the
> > default branch into the vim73 branch. I don't know if the other way
> > around would still work. Or that we need to use export + import.
>
> I don't know how to do this either -- from what I can tell you will
> have to rewrite history in some way (e.g. export+import).
>
> On that topic, will the history of the "default" branch never be
> rewritten (no rebase, etc.)? If so, I will merge the MacVim branch
> against the default branch (and probably keep a topic branch that
> merges against vim73).
used for changes that have been pushed. Thus it's safe to assume the
default branch will keep it's history.
--
% cat /usr/include/life.h
void life(void);
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
James Vega
>
> Björn Winckler wrote:
>
> > I was wondering what the plans for the Mercurial branches are once 7.3
> > is finished. Will "vim73" be merged into "default" at some point, or
> > will there be one giant "vim73 patch" applied to "default" (making all
> > changesets in the "vim73" branch into a patch) and "vim73" will be
> > left, or ...?
> >
> > I am wondering because I am in the process of changing the MacVim repo
> > to use the Vim Mercurial repo as upstream instead of the svn repo.
> > This is to allow me to make an informed decision as to which branch to
> > merge my own "macvim" branch against.
>
> When 7.3 is released it will become the default branch. How this is
> done I don't know. There were some problems when I used "hg rebase" on
> the vim73 branch, now it's no longer possible to merge directly from the
> default branch into the vim73 branch. I don't know if the other way
> around would still work.
Merging vim73 into default should work fine, and it currently does. I
tried it earlier today.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@debian.org>
Gary Johnson
> Björn Winckler wrote:
>
> > I was wondering what the plans for the Mercurial branches are once 7.3
> > is finished. Will "vim73" be merged into "default" at some point, or
> > will there be one giant "vim73 patch" applied to "default" (making all
> > changesets in the "vim73" branch into a patch) and "vim73" will be
> > left, or ...?
> >
> > I am wondering because I am in the process of changing the MacVim repo
> > to use the Vim Mercurial repo as upstream instead of the svn repo.
> > This is to allow me to make an informed decision as to which branch to
> > merge my own "macvim" branch against.
>
> When 7.3 is released it will become the default branch. How this is
> done I don't know. There were some problems when I used "hg rebase" on
> the vim73 branch, now it's no longer possible to merge directly from the
> default branch into the vim73 branch.
the vim repo, which was at changeset a8afba7027ae at the time, and
merged the 7.2.437 patch to the vim73 branch as follows.
hg update vim73
hg merge default
hg ci
I had to manually merge the file that contains the patch list,
version.c, I think, but that was easy using vimdiff.
You should be able to merge each Vim 7.2 patch to the vim73 branch
as it comes along.
Regards,
Gary
Bram Moolenaar
Xavier de Gaye wrote:
> On Sun, May 23, 2010 at 12:38 PM, Bram Moolenaar wrote:
> >
> > ...
> > When 7.3 is released it will become the default branch. =A0How this is
> > done I don't know. ...
> >
>
>
> The 'vim73' branch can be given the name of the 'default' branch with
> the 'hg branch --force default' command after the 'default' branch is
> named 'vim72' with the 'hg branch vim72' command (both followed by
> commit).
>
> A simple test made on a fake repo with 'default' and 'vim73' branches
> (same as in the current vim repo) shows this result after that is done:
>
> $ hg branches
> default 5:ce5266650699
> vim72 4:d5bb6abbab9a
> vim73 3:90078dbe59dd (inactive)
>
> Changeset '3:90078dbe59dd' is the tip of the vim73 branch before it is
> renamed to 'default'.
Now that I'm ready to make vim73 the default branch, it occurs to me
that when I do this, doing "hg update vim73" will stop working.
What I would like to do is keep the "vim73" label on the branch, but
make it the default one.
So currently:
hg clone ... gives you the default branch, Vim 7.2.1234
hg update vim73 switches to Vim 7.3
What I would like to get:
hg clone ... gives you the default branch, Vim 7.3.001
hg update vim73 stays on the default branch
hg update vim72 switches to Vim 7.2.1234
Is that possible? Or does making vim73 the default branch always have
the result that switching to the vim73 branch stops working?
An acceptable alternative would be that the default branch has the
latest version, including patches, while "vim73" is plain 7.3, no patches.
--
hundred-and-one symptoms of being an internet addict:
80. At parties, you introduce your spouse as your "service provider."
Tony Mechelynck
I think it's your "acceptable alternative":
if you make the "default" branch point to the latest 7.3 build -- maybe by
hg update default
hg --config ui.merge=internal:other merge -r vim73
(but watch out for "resurrected" files if you do that) then (IIUC) "hg
update vim73" will forever give you the last 7.3 changeset before the
merge. You may thereafter create a "tag" (pointing to one revision) or a
"branch" (pointing to one revision and all its children excluding other
branches) so that "hg update vim72" would point to 7.2.446 or its latest
"7.2" descendant if any. For a branch you may need to create a new
changeset with no changes, I'm not sure. Or you may wait until 7.2.447
if any and use a --branch argument in the commit for that changeset.
Best regards,
Tony.
--
Bumper sticker:
"All the parts falling off this car are of the very finest British
manufacture"
Tony Mechelynck
Oops, creating a branch is a separate transaction, not an option of hg
commit.
Best regards,
Tony.
--
"Cable is not a luxury, since many areas have poor TV reception."
-- The mayor of Tucson, Arizona, 1989
Xavier de Gaye
>
> Xavier de Gaye wrote:
>>
>> the 'hg branch --force default' command after the 'default' branch is
>> named 'vim72' with the 'hg branch vim72' command (both followed by
>> commit).
>
> Now that I'm ready to make vim73 the default branch, it occurs to me
> that when I do this, doing "hg update vim73" will stop working.
>
> What I would like to do is keep the "vim73" label on the branch, but
> make it the default one.
>
> So currently:
>
> hg clone ... gives you the default branch, Vim 7.2.1234
> hg update vim73 switches to Vim 7.3
>
> What I would like to get:
>
> hg clone ... gives you the default branch, Vim 7.3.001
> hg update vim73 stays on the default branch
I understand that 'branch' is an attribute of a changeset with a
single value ('default' or 'vim73', but not both), so that it is not
possible to have 'hg update default' and 'hg update vim73' give the
same result.
> hg update vim72 switches to Vim 7.2.1234
>
> Is that possible? Or does making vim73 the default branch always have
> the result that switching to the vim73 branch stops working?
>
> An acceptable alternative would be that the default branch has the
> latest version, including patches, while "vim73" is plain 7.3, no patches.
'"vim73" is plain 7.3, no patches' is what happens when the 'vim73'
branch is renamed the 'default' branch after the vim73 release have
been made.
Attached is a shell script that creates a repository in a new
'branch_test' directory and runs a sequence of hg commands that
reproduce what happens when branches are renamed this way. After the
script is run and cloning the repository, the cloned repo behaves as
in the "acceptable alternative" above.
Xavier
Xavier de Gaye
branches in a mercurial repository and to see where is the parent of
the working directory (indicated by '@' in the graph)
See http://mercurial.selenic.com/wiki/GraphlogExtension
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
Thanks. The shell script is especially useful to see what really
happens.
So it's not possible to have two branch names for the same version. I
think what you have done here is most likely the best solution. The
only other alternative I heard is merging the vim73 branch back into
default, but that has more chances of going wrong. And I don't really
seen an advantage, since all changes in the 7.2 branch (called default
until now) have been included in 7.3.
--
hundred-and-one symptoms of being an internet addict:
91. It's Saturday afternoon in the middle of May and you
are on computer.
Xavier de Gaye
>
> Xavier de Gaye wrote:
>
>> > >> The 'vim73' branch can be given the name of the 'default' branch with
>> > >> the 'hg branch --force default' command after the 'default' branch is
>> > >> named 'vim72' with the 'hg branch vim72' command (both followed by
>> > >> commit).
>> > >> ...
>> > >
>> > > Now that I'm ready to make vim73 the default branch, it occurs to me
>> > > that when I do this, doing "hg update vim73" will stop working.
>> > >
Assume that on doing the first branching last may, the reverse had
been done instead, that is:
. the vim73 release is developed on the main branch (the 'default'
NamedBranch)
. creation of a 'vim72' NamedBranch where the critical patches of the main
branch (the 'default' NamedBranch) are retrofited as vim72 patches
. the 'vim73' NamedBranch does not exist
What would have changed:
. no need to 'hg update vim73' when the branch was created (as most
of us probably did at this time)
. no need to 'hg update default' now (without forgetting to do
first a 'hg pull'), once the vim73 release is done
What are the drawbacks of the above scheme ?
Xavier
björn
It would have made life easier for me with maintaining the Git
repository. Renaming the "vim73" branch "default" lead to problems as
I outlined in a recent post. Had the development of vim73 taken place
on the "default" branch I would have had no problems.
I for one would be very happy if the next version (vim74?) used this
scheme (i.e. where all new work happens on the "default" branch).
Björn
Bram Moolenaar
Björn Winckler wrote:
In my opinion the default branch should contain the stable version.
Most users would sync there once in a while to update their Vim.
Developers would want to get the bleeding edge version, and we can
assume the can follow the instructions to sync to a different branch.
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.
--
From "know your smileys":
%-) After staring at screen for 15 hours
Matt Wozniski
>
> Björn Winckler wrote:
>> scheme (i.e. where all new work happens on the "default" branch).
>
> In my opinion the default branch should contain the stable version.
> Most users would sync there once in a while to update their Vim.
Most users don't get their vim from source control at all - they get
it from binaries or source provided by their distro.
> Developers would want to get the bleeding edge version, and we can
> assume the can follow the instructions to sync to a different branch.
>
> 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.
Keep in mind that in most opensource projects work that way - I don't
think I've ever checked out code where the starting branch wasn't the
main development branch. If you want an older version, it's easy to
check out an old tag. With CVS or SVN, you'd always get the latest
HEAD, there's no reason for Hg to be any different.
Just my $0.02
~Matt
James Vega
> 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). 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.
The vim73 head would still exist, but it could be marked as a closed
branch if you didn't want it to show up in the default "hg heads" view.
As such, people could still "hg up vim73" to get the original version
with no patches but it wouldn't clutter the default view.
Speaking of extra heads, would it make sense to mark the spurious vim
head as closed so it doesn't show up in the default view?
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Xavier de Gaye
> 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
James Vega
> 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.
Yes, there are conflicts that need to be merged since development
happened on both branches after vim73 was branched from default. That's
expected and normal but not difficult to deal with and is a one time
cost, for one person, that happens at the time of the merge.
The conflicts that do happen are also simple to resolve though because
you know that you want all of the vim73 changes. You can either
manually use all of them (which is really easy if using Vim to handle
the merge conflicts) or use a method similar to what Tony explained.
> # vim72 into default
> hg clone vim-master foobar
> cd foobar
> hg merge vim72
hg --config ui.merge=internal:local merge vim72
> # default into vim72
> hg clone vim-master foobar
> cd foobar
> hg update vim72
> hg merge default
hg --config ui.merge=internal:other 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
Right, so it's now more complicated for people to interact with the
repository than it previously was.
Ben Fritz
On Aug 17, 4:56 pm, Matt Wozniski <m...@drexel.edu> wrote:
>
> Most users don't get their vim from source control at all - they get
> it from binaries or source provided by their distro.
>
> > Developers would want to get the bleeding edge version, and we can
> > assume the can follow the instructions to sync to a different branch.
>
> > 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.
>
> Keep in mind that in most opensource projects work that way - I don't
> think I've ever checked out code where the starting branch wasn't the
> main development branch. If you want an older version, it's easy to
> check out an old tag. With CVS or SVN, you'd always get the latest
> HEAD, there's no reason for Hg to be any different.
>
When I look at a new project, I personally expect the "latest and
greatest" to be on the main trunk, unless there are spurious
"experimental" branches. I expect that when I want to look at an old
version, I will need to do something special. I expect that most users
will either get pre-compiled binaries when they don't want the
bleeding-edge stuff, or will be willing to do a little extra work to
ensure a stable version.
Maybe we could have a floating "stable" label that moves from time to
time as new versions get used and tested, to limit the amount of
thinking that goes into getting the latest "stable" build?
Tony Mechelynck
>
>
> On Aug 17, 4:56 pm, Matt Wozniski<m...@drexel.edu> wrote:
>>
>> Most users don't get their vim from source control at all - they get
>> it from binaries or source provided by their distro.
>>
>>> Developers would want to get the bleeding edge version, and we can
>>> assume the can follow the instructions to sync to a different branch.
>>
>>> 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.
>>
>> Keep in mind that in most opensource projects work that way - I don't
>> think I've ever checked out code where the starting branch wasn't the
>> main development branch. If you want an older version, it's easy to
>> check out an old tag. With CVS or SVN, you'd always get the latest
>> HEAD, there's no reason for Hg to be any different.
>>
>
> I don't think I can top what Matt says here, I agree whole-heartedly.
> When I look at a new project, I personally expect the "latest and
> greatest" to be on the main trunk, unless there are spurious
> "experimental" branches. I expect that when I want to look at an old
> version, I will need to do something special. I expect that most users
> will either get pre-compiled binaries when they don't want the
> bleeding-edge stuff, or will be willing to do a little extra work to
> ensure a stable version.
Also, the Mercurial documentation says that it is "strongly recommended"
to use the default branch for the branch "where active development is
being done". This would mean the bleeding-edge "latest of the greatest"
which receives the most pushes, not some "stable" branch which will be
retired (possibly after some "grace period" during which it receives
only security and stability updates) once the next release achieves
sufficient stability.
>
> Maybe we could have a floating "stable" label that moves from time to
> time as new versions get used and tested, to limit the amount of
> thinking that goes into getting the latest "stable" build?
>
In Mercurial that would be a "tag" i.e. a label applying to one
changeset, but which can be moved by tagging a later changeset with the
same tag. The "tip" tag is special in that it always means the changeset
most recently added to the repository; other tags can be moved by an
explicit "hg tag" followed by "hg commit". Each changeset may have zero
or more tags. For instance one may want to tag a certain changeset as
both "VERSION_9_5_RC1" and "VERSION_9_5_RELEASE" then if necessary a
later changeset will be tagged "VERSION_9_5_RC2" and
"VERSION_9_5_RELEASE", thus removing the "release" tag from the RC1
build. Then if the RC2 doesn't exhibit release-breaking buggy behaviour,
it will stay as the 9.5 release build with no additional change to the
repository. (I've seen this kind of thing happen recently while lurking
in the #chatzilla channel at irc.mozilla.org, and a robot announced new
tags being defined for SeaMonkey in the Mozilla "comm-central" hg
repository.)
Best regards,
Tony.
--
Politics is like coaching a football team. you have to be smart enough
to understand the game but not smart enough to lose interest.
Tony Mechelynck
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.
Best regards,
Tony.
--
There is no TRUTH. There is no REALITY. There is no CONSISTENCY.
There are no ABSOLUTE STATEMENTS I'm very probably wrong.
sc
> hg fetch --switch-parent
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
sc
> hg fetch --switch-parent
i've also got a [bash] script to merge -- i feel it overkill
to repeat the commit message as tony is doing here, but i've
coded it to allow me to specify a different message if i want
to -- i call it 'u3':
#!/bin/bash
# u3
cd ~/.build/hgvim/vim
dt=`date '+%Y-%b-%d %H:%M'`
echo $dt >> ../update.log
if [ $# -eq 0 ]; then
echo "about to hg commit" >> ../update.log
hg commit -m "$dt -- updates from bram" 2>&1 | tee -a
../update.log
else
echo "about to hg commit $@" >> ../update.log
hg commit "$@" 2>&1 | tee -a ../update.log
fi
dsh >> ../update.log
as you may guess, my first pull i call 'u', so for me a simple
update is as simple as u, u2 `cs`, u3
sc
Xavier de Gaye
> On 18/08/10 14:49, Xavier de Gaye wrote:
>>
>> 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
>>
>
> 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.
You may also run:
hg pull
hg merge -r tip
hg commit -m 'Automated merge with http://vim.googlecode.com/hg/'
Nothing varies in the above three statements, and these statements can
go in a 'my_fetch.sh' script.
The fetch extension has been implemented so as to emulate the behavior
of 'git pull', for people familiar with git I guess. In git, you pull.
In mercurial you pull, then merge or update or wait until a more
appropriate time. Your choice. Mercurial looks more flexible in this
matter. I don't see it as a problem.
Xavier
sc
> You may also run:
unless and until runtime/doc/tags needs a commit, in which
case you'll need an extra commit between the pull and the
merge
i keep thinking it should be easy to write an expect script to
test for merge success and automating that, but i'm too new to
expect for it to be easy for me
sc
Benjamin R. Haskell
This seems overly complicated for one of the most common things one does
with a repository. (get changes from upstream)
Isn't this essentially what the fetch extension does? (So the above
becomes: hg fetch) Or was this not working when there were two heads?
> The fetch extension has been implemented so as to emulate the behavior
> of 'git pull', for people familiar with git I guess. In git, you pull.
> In mercurial you pull, then merge or update or wait until a more
> appropriate time. Your choice. Mercurial looks more flexible in this
> matter. I don't see it as a problem.
Actually, it seems like hg fetch (pull in new changes, merge if needed)
is roughly equivalent to git pull (fetch new changes, merge if needed).
So, confusingly:
hg pull ~= git fetch
hg fetch ~= git pull
In Gitopia, you fetch changes from the remote server, then pull them
into your local work. In Mercurialand, you pull changes from the remote
server and then fetch(?) them into your repository. (My preferred
nomenclature bias might be evident, here.)
--
Best,
Ben
Tony Mechelynck
runtime/doc/tags is one of my "local changes" to .hgignore, so if and
when it is changed remotely (which "hg incoming" warns me about) I
answer d<Enter> when "hg fetch" (or "hg merge") asks me whether to use
remote version or leave deleted. ("make install" or "make
installruntime" rebuild it from scratch anyway, by running
vim -u NONE -esX -c "helptags ++t ." -c quit
[the "vimtags" target for runtime/doc/Makefile] at least on Linux where
I am.)
Testing for merge success: doesn't hg merge return $? == 0 (TRUE) iff it
succeeds? Or you could parse the output of "hg status" and/or "hg
summary" for uncommitted changes _before_ pulling. BTW "hg incoming"
returns 1 if there is nothing to be pulled so you could check that too.
Best regards,
Tony.
--
Alex Haley was adopted!
Tony Mechelynck
hg fetch does that without the "-r tip" switch to merge, failing if the
merge doesn't see exactly two heads (one with local changes and one
newly pulled) on that branch. If the remote "master" repo has two heads
for the branch, it fails as soon as you have local changes (as I have in
.hgignore and src/feature.h).
>
>
>> The fetch extension has been implemented so as to emulate the behavior
>> of 'git pull', for people familiar with git I guess. In git, you pull.
>> In mercurial you pull, then merge or update or wait until a more
>> appropriate time. Your choice. Mercurial looks more flexible in this
>> matter. I don't see it as a problem.
>
> Actually, it seems like hg fetch (pull in new changes, merge if needed)
> is roughly equivalent to git pull (fetch new changes, merge if needed).
>
> So, confusingly:
>
> hg pull ~= git fetch
> hg fetch ~= git pull
>
> In Gitopia, you fetch changes from the remote server, then pull them
> into your local work. In Mercurialand, you pull changes from the remote
> server and then fetch(?) them into your repository. (My preferred
> nomenclature bias might be evident, here.)
>
hg fetch ~= hg pull && hg merge && hg commit -m "Automated merge from
${paths.default}"
In Mercurialand, you pull new metadata into your repository then locally
update your working directory. Or maybe merge outstanding topological
branches then commit the result. Fetching is a nondefault extension,
roughly equivalent to pull+merge+commit, chiefly (IMHO) for use on
pull-only repositories with local changes. (By pull-only I mean that you
won't need to push from them.)
Also, in Mercurialand (and assuming the necessary privileges are set) if
repositories A and B are related (by one being a clone of the other, or
both clones of a 3rd one) pushing and pulling are reciprocal operations:
if user A pushes from his repo to to repository B, or user B pulls from
repository A, the result is supposed to be the same.
Best regards,
Tony.
--
"They told me I was gullible ... and I believed them!"