On 23/05/10 22:29, Gary Johnson wrote:
On 2010-05-23, sc<[email protected]> wrote:
my hg repo got horked -- it was fine til i did something wrong
today and everything i tried made it worse -- i had 6 heads in
my repo and merge always found inscrutable ways of failing
my falback, blowing away the entire directory and starting with a
fresh clone is proving problematical
about the only thing i know i can do and do successfully is the
clone, which i've done several times now but can't seem to get
back to 7.3 -- what i am winding up with is 7.2.437
I think you're missing update,
hg update vim73
which you should do after the clone and before editing any files.
That will select the branch or revision that will be the parent of
your working copy. I usually think of 'update' as changing my view
into the repo, or as changing the revision that I'm working on, but
that's not quite right and I'm trying to change my mental model and
my vocabulary to match what Mercurial actually does.
it doesn't sound bad. IIUC "update" means updating the working copy (the
actual vim-related files) to a certain revision, tag or branch.
Since "hg clone" will normally pull/update the default branch, if you
want to set up a vim73 repo you can skip getting the Vim 7.2 files by using
hg clone -U <url> <dirname>
cd <dirname>
hg up vim73
(where <url> is the URL of Bram's repo and <dirname> is the name you
want to give to the top directory of your clone). You may also want to
set up ~/.hgrc and/or <dirname>/.hg/hgrc, see "man hgrc" if you're on
Unix, and there are some examples below. In general there are several
levels of hgrc files, as follows:
- installation-level
- on Unix: one or more of
<install-root>/etc/mercurial/hgrc
<install-root>/etc/mercurial/hgrc.d/*rc
where <install-root> is the parent of the directory containing
the hg executable, e.g. /usr if Mercurial is /usr/bin/hg
- on Windows: one of
<install-dir>\Mercurial.ini
HKEY_LOCAL_MACHINE\Software\Mercurial
C:\Mercurial\Mercurial.ini
- system-level (for all users)
- on Unix: one of
/etc/mercurial/hgrc
/etc/mercurial/hgrc.d/*.rc
- on Windows, this level is not distinct from the above
- user-level (for all repositories of that user)
- on Unix:
$HOME/.hgrc
- on Windows: one of
%HOME%\Mercurial.ini
%HOME%\.hgrc
%USERPROFILE%\Mercurial.ini
%USERPROFILE%\.hgrc
on Win9x use %APPDATA% instead of %HOME%
- repository-level (for a single repository)
<repository>/.hg/hgrc
When conflicting settings appear at different levels, the most
particular one (the last one in the order above) wins.
if i have done a clone, if i have modified feature.h and
committed that, how do i then tell hg i want to build against 7.3
and not 7.2?
If you seem to be building Vim 7.2, then you're probably using the
default branch. If you've already committed feature.h, you probably
committed it on the default branch, too.
If it's easy to start over again, I would do that, because anything
else requires hg manipulations that I'm not all that familiar with
yet.
If you haven't already done so, I'd recommend adding graphlog and
pager to your list of extensions. All you have to do is add to your
~/.hgrc:
[extensions]
hgext.graphlog =
hgext.pager =
[pager]
pager = LESS='FRX' less
attend = annotate, cat, diff, export, glog, help, log, qdiff
For the pager, a nice alternative (for us Vimmers) is
pager = view -
(or gview - ). [pager] header and attend= parameters as above. I use
[g]view (or [g]vim -R) so the buffer will be marked 'readonly' and
'nomodified', thus preventing an error message on :q -- of course you
can always use the :saveas command if you want to keep it.
Then you can use
hg glog
to see a graphical representation of the repo's log along with an @
indicator showing your current parent(s). That has really helped me
to visualize the effects of my hg operations.
Yes, "hg glog" (or "hg log -G") adds a nice "ASCII art" column on the
left of the history, showing how the various revisions are related. You
may want to limit the number of entries printed by using -l <number>,
otherwise everything (more than 2000 entries in the Vim repo) will be
displayed, usually with a half-dozen lines or so per entry (if many
files were modified at a single revision, the "line" listing them may be
very long: in some extreme cases I've seen "one line" filling my 80x43
terminal all by its ownself.)
HTH,
Gary
Another nice little extension is the "children" extension, which gives
an "hg children -r <revision>" command, reciprocal to "hg parents -r
<revision>" so you can follow the tree not only from leaf to root but
also vice-versa.
Here's the [ui] section of my ~/.hgrc (for "any" Mercurial repos that I
may have). Of course you'll want a different "username" line, the rest
may or may not suit you.
[ui]
username = Tony Mechelynck <[email protected]>
merge = internal:merge
editor = vim
verbose = true
If you choose gvim as the editor instead, you'll want to add -f so it
won't fork, and Mercurial can use what gvim wrote (e.g. a commit
message) after the gvim process finishes.
Best regards,
Tony.
--
Health is merely the slowest possible rate at which one can die.
--
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
