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...
For managing several Vim builds in parallel (let's say huge and tiny,
which is what I have, or maybe with and without GUI enabled) by means of
shadow directories, I've added a few lines to .hgignore (see attached
patch -- also for cscope). Bram, what do you think?
However, it seems that cscope does not follow symlinks, so it cannot be
used in a shadow directory.
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. Finally I
found that the hgext.fetch extension (distributed with Mercurial but
disabled by default) seems to do what I need, and I also found the way
to enable it (by means of .hg/hgrc), but I couldn't yet try it out -- I
found it after patch 7.2.422 was distributed and then Bram stopped for
today ;-). -- BTW there is some doubletalk in the hg manpages and help
about the difference between the first and second parent of the commit
that follows a merge (or the merge done by a fetch) but I haven't yet
grasped what it means. Oh, and I also haven't found how to remove the
nonsense label after the last @@ in a hunk of an hg diff, my hgrc
(attached) doesn't cut it (it was used to produce the attached diff).
Once I have the process steamrolled I'll update my HowTo page about
building Vim on Unix/Linux (or maybe add a third page or write a VimTip)
but I'm not there yet.
Best regards,
Tony.
--
Every little picofarad has a nanohenry all its own.
-- Don Vonada
--
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
[paths]
default = https://vim.googlecode.com/hg/
[extensions]
hgext.fetch =
[diff]
git = False
showfunc = False
[ui]
verbose = True
diff -r d297871cd49c .hgignore
--- a/.hgignore Thu May 13 17:57:06 2010 +0200
+++ b/.hgignore Thu May 13 21:41:48 2010 +0200
@@ -39,3 +39,15 @@ gvimext.lib
*.orig
*.mo
*~
+
+# shadow directories
+# the directory names could be anything but we restrict them
+# to shadow (the default) or shadow-*
+src/shadow
+src/shadow-*
+# src/runtime and src/pixmaps are softlinks needed for proper 'make install'
+# when in a shadow directory
+src/runtime
+src/pixmaps
+# avoid tracking cscope.out even if built here
+src/cscope.out
