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.
( 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
--
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
