On 14/05/2010 04:11, Tony Mechelynck wrote:
On 13/05/10 23:42, Gary Johnson wrote:
On 2010-05-13, Tony Mechelynck wrote:
[snip]
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.
The mq extension for managing a stack of local patches/local changes.
The usual idiom is to pop all currently active patches (hg qpop --all)
to get back to the base repo status, do a pull and update and then push
all that patches back onto the source files (hg qpush --all or named
patch if don't want all to be reapplied).
mq is a nice little system for working on changes while keeping your
local repo in line with the main one and well worth getting familiar with.
HTH - TTFN
Mike
--
I was denied life insurance, they said I had to get a life first.
--
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
