On 13/05/10 23:42, Gary Johnson wrote:
On 2010-05-13, Tony Mechelynck wrote:
I've started trying to learn Mercurial as used with Vim, but the
learning curve is steep, not the least because AFAICT the only docs
consist in three very long manpages, plus the "hg help" function which
only displays a few lines at a time (let's say between 10 and 60) and
you cannot know what an "extension" exactly does before you enable it:
hg help<command> gives an error if<command> is disabled, which is by
default the case of most extensions; the list of extensions under "hg
help extensions" (there is none in the manual) consists of only one line
per extension. -- Ah la la, I've been too cuddled by the Vim help, I've
lost the habit of puzzling out an answer through extremely long manpages
and extremely short help screens, where help screens and manpages each
contain info not available in the other set...
I've recently started learning Mercurial myself, largely for
managing my own work. I've been using Google to find the answers to
most of my questions. There is a lot of good information,
especially on extensions, on the wiki:
http://mercurial.selenic.com/wiki/
Google has also revealed a number of good tutorials, e.g.,
http://mercurial.selenic.com/wiki/UnderstandingMercurial
http://mercurial.selenic.com/wiki/Tutorial
http://hginit.com/
http://hgbook.red-bean.com/
http://mercurial.aragost.com/kick-start/
thanks for the pointers, I'll be remembering to come back to this email.
When building exclusively from "official" sources, Mercurial is (all in
all) rather easy to use (once "hg clone https://vim.googlecode.com/hg/
vim" to create the repository, which includes a reasonable .hgignore for
compiling one build only from vanilla sources, and any number of times
"hg pull -u" as updates are published). However, I have a few "home
patches", one of which adds an "Extra patch" near the end of version.c
-- with the patches distributed by ftp this was no problem, as this
change is after the added patches: patch doesn't even notice it. But
with Mercurial as distributed it meant hg pull, hg merge, hg commit (3
separate Mercurial functions) for each patch (or set of patches) pulled,
because Mercurial notices that version.c has been modified by Bram and
needs to be merged -- every time -- with the change I made.
There's a whole Mercurial subsystem (my term) for managing patches,
Mq, but it seems really complicated, so I haven't tried using it.
You might take a look at the rebase and attic extensions for a
simpler approach to managing your own patches.
HTH,
Gary
What I've done is made a "local changeset" and committed it, then found
out that for every new official patch it was the pull-merge-commit
rigmarole again. I expect that with the fetch extension it'll be a lot
smoother.
From what I've seen of mq it's useful when constantly receiving or
sending patches in diff form, which is not what I do (I keep my "own
changes", which are few, in diff form because of ease of use and
robustness against other changes, but with Mercurial I get Bram's
changes in whatever format Mercurial uses internally, via hg pull). It
has a lot of subcommands and I don't have the use of all that ATM.
Best regards,
Tony.
--
!07/11 PDP a ni deppart m'I !pleH
--
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
