Vim/Mercurial: "default" branch has two heads
Tony Mechelynck
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)):
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.
Best regards,
Tony.
--
BEDEVERE: Stand by for attack!!
[CUT TO enormous army forming up. Trebuchets, rows of PIKEMEN, siege
towers, pennants flying, shouts of "Stand by for attack!" Traditional
army build-up shots. The shouts echo across the ranks of the army.
We see various groups reacting, and stirring themselves in readiness.]
ARTHUR: Who are they?
BEDEVERE: Oh, just some friends!
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
Bram Moolenaar
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?
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!
--
There's no place like $(HOME)!
/// 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 ///
Tony Mechelynck
>
> 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.
OK.
Best regards,
Tony.
--
The more things change, the more they stay insane.
Bram Moolenaar
Tony Mechelynck wrote:
I have done this now. Please let me know ASAP if there is something
wrong.
--
I AM THANKFUL...
...for the piles of laundry and ironing because it means I
have plenty of clothes to wear.
Tony Mechelynck
I can't see anything wrong:
- hg diff shows me no file differences between the latest two
changesets, which is the desired effect;
- hg heads shows only one head per branch, the "default" branch head
being the new changeset, which is again the desired effect;
- hg branches shows vim (near the base of the tree), vim72, vim73 and
default, each pointing to the expected changesets (the same ones as
shown by "hg heads"); the vim73 branch is listed as "inactive" because
it has a child (in the default branch). All this looks normal to me.
Thanks :-), and happy Vimming!
Tony.
--
Please take note:
Benjamin R. Haskell
> I can't see anything wrong:
>
> - hg diff shows me no file differences between the latest two
> changesets, which is the desired effect;
> - hg heads shows only one head per branch, the "default" branch head
> being the new changeset, which is again the desired effect;
> - hg branches shows vim (near the base of the tree), vim72, vim73 and
> default, each pointing to the expected changesets (the same ones as
> shown by "hg heads"); the vim73 branch is listed as "inactive" because
> it has a child (in the default branch). All this looks normal to me.
This seems abnormal to me, but it might be my own semantic dissonance
with hg...
Shouldn't current development be on the vim73 branch? Can the vim73
branch not be equivalent to the default branch? (Can a branch in hg
have multiple names?) Can the vim73 branch just be used as the default
(without calling it 'default')?
I would expect there to be a tag that could get you vim 7.3(.0.0) if you
wanted it, but it seems weird that there are new patches (releases) of
vim 7.3 with the vim73 branch being "inactive".
--
Best,
Ben
Tony Mechelynck
> On Fri, 20 Aug 2010, Tony Mechelynck wrote:
>
>> I can't see anything wrong:
>>
>> - hg diff shows me no file differences between the latest two
>> changesets, which is the desired effect;
>> - hg heads shows only one head per branch, the "default" branch head
>> being the new changeset, which is again the desired effect;
>> - hg branches shows vim (near the base of the tree), vim72, vim73 and
>> default, each pointing to the expected changesets (the same ones as
>> shown by "hg heads"); the vim73 branch is listed as "inactive" because
>> it has a child (in the default branch). All this looks normal to me.
>
> This seems abnormal to me, but it might be my own semantic dissonance
> with hg...
>
> Shouldn't current development be on the vim73 branch? Can the vim73
> branch not be equivalent to the default branch? (Can a branch in hg
> have multiple names?) Can the vim73 branch just be used as the default
> (without calling it 'default')?
A changeset always belongs to exactly one named branch, so it is not
possible to make the default branch and the vim73 branch "equivalent".
(The default branch is also a named branch, it's just that the line
"branch: default" is omitted in hg log listings).
The Mercurial team "strongly recommends" that the default branch be the
code branch undergoing active development, where pushes will happen most
often.
I suppose that at the time of vim 7.2 vs. 7.3a branching, the branch
which was going to evolve into Vim 7.3 should have kept the "default"
branch name (and been seen as the "trunk"), while the 7.2 branch (which
would "die" after the 7.3 release) should have been named vim72 at that
point. For better or worse this is not what happened.
>
> I would expect there to be a tag that could get you vim 7.3(.0.0) if you
> wanted it, but it seems weird that there are new patches (releases) of
> vim 7.3 with the vim73 branch being "inactive".
>
"inactive" means that it is not a topological head, i.e., this branch
head has one or more children in a different branch. This is because
development on the "vim73" named branch was halted when it was decided
to continue it as the (new) "default" branch.
The expression "inactive branch" is deprecated in current Mercurial
releases, now that it is possible to "close" a branch (by means of hg
commit --close-branch), which is a different thing.
For details, you may subscribe to the Mercurial mailing list, mercurial
-at- selenic.com; see http://selenic.com/mailman/listinfo/mercurial for
more info about that list. See also the Mercurial project site
http://mercurial.selenic.com/ and in particular the "Mercurial Guide"
http://mercurial.selenic.com/guide/
Best regards,
Tony.
--
Real programmers don't write in BASIC. Actually, no programmers write
in BASIC after reaching puberty.
Benjamin R. Haskell
> On 20/08/10 17:48, Benjamin R. Haskell wrote:
> > On Fri, 20 Aug 2010, Tony Mechelynck wrote:
> >
> > > I can't see anything wrong:
> > >
> > > - hg diff shows me no file differences between the latest two
> > > changesets, which is the desired effect;
> > > - hg heads shows only one head per branch, the "default" branch
> > > head being the new changeset, which is again the desired effect;
> > > - hg branches shows vim (near the base of the tree), vim72, vim73
> > > and default, each pointing to the expected changesets (the same
> > > ones as shown by "hg heads"); the vim73 branch is listed as
> > > "inactive" because it has a child (in the default branch). All
> > > this looks normal to me.
> >
> > This seems abnormal to me, but it might be my own semantic
> > dissonance with hg...
> >
> > Shouldn't current development be on the vim73 branch? Can the vim73
> > branch not be equivalent to the default branch? (Can a branch in hg
> > have multiple names?) Can the vim73 branch just be used as the
> > default (without calling it 'default')?
>
> A changeset always belongs to exactly one named branch, so it is not
> possible to make the default branch and the vim73 branch "equivalent".
Okay. I suppose that's de rigueur anyway. (I often end up with
multiple branches in Git that point to the same commit, when I just
neglect to do anything with them, but I guess what I was implying
doesn't actually exist in Git either.)
> (The default branch is also a named branch, it's just that the line
> "branch: default" is omitted in hg log listings).
>
> The Mercurial team "strongly recommends" that the default branch be
> the code branch undergoing active development, where pushes will
> happen most often.
>
> I suppose that at the time of vim 7.2 vs. 7.3a branching, the branch
> which was going to evolve into Vim 7.3 should have kept the "default"
> branch name (and been seen as the "trunk"), while the 7.2 branch
> (which would "die" after the 7.3 release) should have been named vim72
> at that point. For better or worse this is not what happened.
Okay. Looking forward, though, since the current situation still seems
wrong to me:
(2574)----(2575) <-- "vim73" branch ("inactive")
\
\
(2576)----(2577 = 7.3.002)----(2578 also 7.3.002?) <-- "default" branch (w/ vim 7.3 development)
When development for vim 7.4a begins, wouldn't it be a better idea to
branch off a 'vim73' again? So we end up with:
(7.3.998)----(7.3.999) <-- "inactive"/"closed" vim73 branch
\
\
(7.4a)----(7.4b)----(7.4c) <-- "default" branch
I think that could be accomplished by merging 'default' back in to
vim73... but probably a discussion to be had when it comes up.
( While somewhat on the topic, BTW, is there any reason there aren't hg
tags for any patch level past 7.2.325? )
> For details, you may subscribe to the Mercurial mailing list,
> mercurial -at- selenic.com; see
> http://selenic.com/mailman/listinfo/mercurial for more info about that
> list. See also the Mercurial project site
> http://mercurial.selenic.com/ and in particular the "Mercurial Guide"
> http://mercurial.selenic.com/guide/
I gave Mercurial a chance a while back, and I really loved it, compared
to SVN and CVS, which were the other systems I knew at the time. And I
still think it's vastly superior to SVN and love its plugin system (had
a few Python-based plugins I wrote for myself).
But, at this point, I've already drunk the Git Kool-Aid, and there's no
turning back. I'm too enamored of the 'index as staging area'[1] and
'cheap local branches'[2] features, and Mercurial's lack of history
modification just seals the deal.
I actually do all of my Vim development against a Git repository created
with hg-fast-export[3]. (admittedly limited development, but still.)
--
Best,
Ben
[1] http://whygitisbetterthanx.com/#the-staging-area
[2] http://whygitisbetterthanx.com/#cheap-local-branching
[3] http://repo.or.cz/w/fast-export.git
Tony Mechelynck
Not sure... maybe something like
(7.3.245)----(7.3.246)----(7.4a.000)----(7.4a.001)-..-(7.4b)-> (default)
\
(7.3.247)---(7.3.248)--...--(7.3.255)-> (7_3_BRANCH)
If a "not yet used" name is chosen when branching 7.3 off the trunk,
then there will be no confusion with the "vim73" branch that ended with
7.3.000 or somesuch. Or else go again (hopefully for the last time)
through the internal:local merge rigmarole.
Or the following would make the branch "active" again (by creating a new
changeset in the vim73 branch), but not displayed by default in the "hg
branches" listing (because it would be "closed"):
hg update -r vim73
hg commit --close-branch
hg update -r default
>
>
> ( While somewhat on the topic, BTW, is there any reason there aren't hg
> tags for any patch level past 7.2.325? )
Changesets up to tag v7-2-325 had username "vimboss". Then there is one
changeset with username "convert-repo", then later changesets have
username "Bram Moolenaar <br...@zimbu.org>" until the first "vim73"
changeset, and "Bram Moolenaar <br...@vim.org> after that.
Conclusion: changesets up to 7.2.325 were originally pushed on a
different versioning software, maybe by Bram on CVS, maybe by someone
else on a git or SVN mirror.
You can get back at any particular changeset after that by checking the
commit messages, for instance with an hgrc containing
[extensions]
pager=
[pager]
pager=view -
attend=annotate, cat, diff, export, glog, log, manifest, qdiff
so "hg log" (among others) will display its output in a Vim pager.
>
>
>> For details, you may subscribe to the Mercurial mailing list,
>> mercurial -at- selenic.com; see
>> http://selenic.com/mailman/listinfo/mercurial for more info about that
>> list. See also the Mercurial project site
>> http://mercurial.selenic.com/ and in particular the "Mercurial Guide"
>> http://mercurial.selenic.com/guide/
>
> I gave Mercurial a chance a while back, and I really loved it, compared
> to SVN and CVS, which were the other systems I knew at the time. And I
> still think it's vastly superior to SVN and love its plugin system (had
> a few Python-based plugins I wrote for myself).
>
> But, at this point, I've already drunk the Git Kool-Aid, and there's no
> turning back. I'm too enamored of the 'index as staging area'[1] and
> 'cheap local branches'[2] features, and Mercurial's lack of history
> modification just seals the deal.
The more I see it, the more I agree with Mercurial's "frozen history".
Otherwise, how could I know that my repo remains in sync with Bram's
master repo? For a similar reason I won't touch the mq extension if ever
I can avoid it.
>
> I actually do all of my Vim development against a Git repository created
> with hg-fast-export[3]. (admittedly limited development, but still.)
>
> [1] http://whygitisbetterthanx.com/#the-staging-area
> [2] http://whygitisbetterthanx.com/#cheap-local-branching
> [3] http://repo.or.cz/w/fast-export.git
If it works for you, then do it (after all, if git is the versioning
software preferred by Linus Torvalds it must not be /too/ bad). I never
used another versioning system before, but I'm starting to get a feeling
for how Mercurial works. Already twice I've deleted my clone and
restarted from scratch but I hope this one will last. (If I had known
then what I know now, maybe I would have found a better solution). Of
course, compared with Vim's, any other software documentation looks
awfully spotty and incomplete, so the "hg help", the manuals and the
online guide are not enough, I also lurk on the mailing list even if
much of what is said there doesn't concern me � or passes my understanding.
Best regards,
Tony.
--
Of all the animals, the boy is the most unmanageable.
-- Plato
Benjamin R. Haskell
Possibly better to avoid confusion, yes.
> Or else go again (hopefully for the last time) through the
> internal:local merge rigmarole.
>
> Or the following would make the branch "active" again (by creating a
> new changeset in the vim73 branch), but not displayed by default in
> the "hg branches" listing (because it would be "closed"):
>
> hg update -r vim73
> hg commit --close-branch
> hg update -r default
Since (presumably) development will be a linear history (non-branching) between now and the time this new branch
would be created, it seems like a merge of default into vim73 would be
conflict-free and accomplish getting the vim73 branch in sync with the
last revisions of vim 7.3. Then development on vim 7.4 could start on
'default'.
> > ( While somewhat on the topic, BTW, is there any reason there aren't
> > hg tags for any patch level past 7.2.325? )
>
> Changesets up to tag v7-2-325 had username "vimboss". Then there is
> one changeset with username "convert-repo", then later changesets have
> username "Bram Moolenaar <br...@zimbu.org>" until the first "vim73"
> changeset, and "Bram Moolenaar <br...@vim.org> after that.
>
> Conclusion: changesets up to 7.2.325 were originally pushed on a
> different versioning software, maybe by Bram on CVS, maybe by someone
> else on a git or SVN mirror.
>
> You can get back at any particular changeset after that by checking
> the commit messages, for instance with an hgrc containing
>
> [extensions]
> pager=
> [pager]
> pager=view -
> attend=annotate, cat, diff, export, glog, log, manifest, qdiff
>
> so "hg log" (among others) will display its output in a Vim pager.
Yeah, but the point of having tags in the first place is to avoid having
to scan commit messages to arrive at an easily-named changeset.
> > > For details, you may subscribe to the Mercurial mailing list,
> > > mercurial -at- selenic.com; see
> > > http://selenic.com/mailman/listinfo/mercurial for more info about
> > > that list. See also the Mercurial project site
> > > http://mercurial.selenic.com/ and in particular the "Mercurial
> > > Guide" http://mercurial.selenic.com/guide/
> >
> > I gave Mercurial a chance a while back, and I really loved it, compared
> > to SVN and CVS, which were the other systems I knew at the time. And I
> > still think it's vastly superior to SVN and love its plugin system (had
> > a few Python-based plugins I wrote for myself).
> >
> > But, at this point, I've already drunk the Git Kool-Aid, and there's no
> > turning back. I'm too enamored of the 'index as staging area'[1] and
> > 'cheap local branches'[2] features, and Mercurial's lack of history
> > modification just seals the deal.
>
> The more I see it, the more I agree with Mercurial's "frozen history".
> Otherwise, how could I know that my repo remains in sync with Bram's
> master repo? For a similar reason I won't touch the mq extension if
> ever I can avoid it.
The fact that changeset ID's are hashes is what ensures your repository
is in sync. Even though Git has changeable history, it's still trivial
to detect whether the remote branches of your repository are in sync.
It doesn't make sense to change history that's already been shared
(since that only leads to confusion and problems), but right now my Vim
Mercurial repo seems to be broken (I have weird merge commits that were caused
by using fetch after I made and committed local changes). If it were a
Git repo, I could obliterate the messy, local changes and nicely resync
my repository without having to clone or re-download it in its entirety.
I think 'mq' would actually help me out here. I don't remember the
day-to-day commands to use it, but IIRC, it provides what I want: a
cleanly synced repository, with my own local changes safely cached away
without merges/etc.
> > I actually do all of my Vim development against a Git repository
> > created with hg-fast-export[3]. (admittedly limited development,
> > but still.)
> >
> > [1] http://whygitisbetterthanx.com/#the-staging-area
> > [2] http://whygitisbetterthanx.com/#cheap-local-branching
> > [3] http://repo.or.cz/w/fast-export.git
>
>
> If it works for you, then do it (after all, if git is the versioning
> software preferred by Linus Torvalds it must not be /too/ bad). I
> never used another versioning system before,
Neither CVS nor SVN?
> but I'm starting to get a feeling for how Mercurial works. Already
> twice I've deleted my clone and restarted from scratch but I hope this
> one will last. (If I had known then what I know now, maybe I would
> have found a better solution).
My favorite article about why someone preferred Git[1] has the great line:
"Git means never having to say, 'You should have'". (Your deleting your
clone and starting from scratch reminded me of that.)
[1] http://tomayko.com/writings/the-thing-about-git
> Of course, compared with Vim's, any other software documentation looks
> awfully spotty and incomplete,
Hear, hear.
> so the "hg help", the manuals and the online guide are not enough, I
> also lurk on the mailing list even if much of what is said there
> doesn't concern me — or passes my understanding.
The Git documentation is horribly technical. Until I finally felt
comfortable with the basic concepts, it was pulling teeth to find
anything useful. Now, though, it feels really good (but only because I
myself am horribly technical). I still can't imagine suggesting Git
over Mercurial to a non-programmer, for example.
--
Best,
Ben
Tony Mechelynck
> On Sat, 21 Aug 2010, Tony Mechelynck wrote:
>> You can get back at any particular changeset after that by checking
>> the commit messages, for instance with an hgrc containing
>>
>> [extensions]
>> pager=
>> [pager]
>> pager=view -
>> attend=annotate, cat, diff, export, glog, log, manifest, qdiff
>>
>> so "hg log" (among others) will display its output in a Vim pager.
>
> Yeah, but the point of having tags in the first place is to avoid having
> to scan commit messages to arrive at an easily-named changeset.
Sure. I can't read Bram's mind; maybe he thought adding the tag on every
patchlevel was an unnecessary hassle? or maybe he didn't want to delve
into the subtilities of the hg tag command? or maybe he thought only the
latest changeset on either the stable or the development branch would
ever be worth reaching? Maybe something else? Maybe some combination of
all of the above?
[...]
>> If it works for you, then do it (after all, if git is the versioning
>> software preferred by Linus Torvalds it must not be /too/ bad). I
>> never used another versioning system before,
>
> Neither CVS nor SVN?
Nothing.
[...]
>> Of course, compared with Vim's, any other software documentation looks
>> awfully spotty and incomplete,
>
> Hear, hear.
:-D
[...]
Best regards,
Tony.
--
Computer programmers do it byte by byte