On 20/08/10 21:35, Benjamin R. Haskell wrote:
On Fri, 20 Aug 2010, Tony Mechelynck wrote:
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.
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 <[email protected]>" until the first "vim73"
changeset, and "Bram Moolenaar <[email protected]> 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
--
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
