On Sat, 21 Aug 2010, Tony Mechelynck wrote:
> On 20/08/10 21:35, Benjamin R. Haskell wrote:
> > On Fri, 20 Aug 2010, Tony Mechelynck wrote:
> >
> > > (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.
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 <[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.
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
--
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
