Mercurial repository available for Vim
Bram Moolenaar
I have setup a Mercurial repository. It contains the same files that
are in CVS, plus the updated runtime files.
You can checkout the files with this command:
hg clone https://vim.googlecode.com/hg/ vim
For most machines you can install a Mercurial package that has the "hg"
command. More info here: http://mercurial.selenic.com/
The initial checkout takes a few minutes. After that updates should be
fast with:
hg pull
hg update
Let me know if something looks wrong. Once this is "approved" by
vim-dev I'll publish it to a larger audience.
--
You can't have everything. Where would you put it?
-- Steven Wright
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Mike Williams
On 07/01/2010 16:28, Bram Moolenaar wrote:
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
>
> You can checkout the files with this command:
>
> hg clone https://vim.googlecode.com/hg/ vim
>
> For most machines you can install a Mercurial package that has the "hg"
> command. More info here: http://mercurial.selenic.com/
>
> The initial checkout takes a few minutes. After that updates should be
> fast with:
>
> hg pull
> hg update
>
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
I get a bunch of the following warnings from cloning to a Windows machine:
WARNING: runtime/macros/hanoi/hanoi.vim already has CRLF line endings
and does not need EOL conversion by the win32text plugin.
Before your next commit, please reconsider your encode/decode settings in
Mercurial.ini or H:\vim\vim\.hg\hgrc.
I have no special encode/decode settings (checked all the config files),
just what comes out of the box with Mercurial.
This is surprising as I have a private Unix based Mercurial repository
for 7.2 patches and don't see this problem pulling to the Windows box.
Could it be from a setting on the repository being pulled from?
Mike
--
Education is what you get from reading the small print; experience is
what you get from not reading it.
David Fishburn
>
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
>
> You can checkout the files with this command:
>
> hg clone https://vim.googlecode.com/hg/ vim
>
> For most machines you can install a Mercurial package that has the "hg"
> command. More info here: http://mercurial.selenic.com/
>
> The initial checkout takes a few minutes. After that updates should be
> fast with:
>
> hg pull
> hg update
>
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
I have never used Mercurial before.
Following the instructions above on a Windows machine worked:
requesting all changes
adding changesets
adding manifests
adding file changes
added 2036 changesets with 16823 changes to 2419 files (+1 heads)
updating to branch default
2256 files updated, 0 files merged, 0 files removed, 0 files unresolved
Only thing I might suggest for other newbies like myself, is to show
to create the vim directory before running the clone command. This
also demonstrates what directory level you should be at when you run
the command.
> You can checkout the files with this command:
> mkdir vim
> hg clone https://vim.googlecode.com/hg/ vim
That will make it clear that you should be one directory up when you
perform the checkout.
After the checkout, my usual build procedure also worked using VS 2008.
Dave
Gary Johnson
>
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
I just set up repositories and built vim on two machines, one
running Red Hat Enterprise Linux WS release 4 and hg version 1.0.2
and another running Cygwin 1.5 with Windows XP and (Cygwin) hg
version 1.3.1. Both installations went flawlessly. I will try with
Cygwin 1.7 on another machine this evening.
Thank you _so_ much for setting this up. This will make it a lot
easier for me to keep my vim installations up to date.
Regards,
Gary
Navdeep Parhar
> ...
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
I'm able to pull the repository and build + install from the local
copy on FreeBSD 8, Solaris 10u8, and OpenSolaris 2009.06 systems.
One question - how do you intend to manage branches? The subversion
repo had a vim7 and other vim7.X directories within the main repo if I
remember correctly.
Maintaining patches on top of vim is now simple with mq, and catching
up is just a rebase. Life is good.
Regards,
Navdeep
Dennis Benzinger
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
>
> You can checkout the files with this command:
>
> hg clone https://vim.googlecode.com/hg/ vim
>
> For most machines you can install a Mercurial package that has the "hg"
> command. More info here: http://mercurial.selenic.com/
>
> The initial checkout takes a few minutes. After that updates should be
> fast with:
>
> hg pull
> hg update
>
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
Everything went OK. I could clone and compile without any problems on my
Linux machine.
Thanks for the repo!
Dennis Benzinger
Antonio Colombo
--
/||\ | Antonio Colombo
/ || \ | ant...@geekcorp.com
/ () \ | azc...@gmail.com
(___||___) | az...@yahoo.com
Bram Moolenaar
Mike Williams wrote:
I don't see this problem (on Windows 7, using Mercurial 1.4.2).
Building with MingW works.
Perhaps your Mercurial is older?
--
From "know your smileys":
...---... SOS
Chris Sutcliffe
> are in CVS, plus the updated runtime files.
<snip>
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
Just curious, is the plan for this Mercurial repository to be the
'main' repository for Vim (like CVS is today)?
Chris
--
Chris Sutcliffe
http://emergedesktop.org
winterTTr
I have setup a Mercurial repository. It contains the same files that
are in CVS, plus the updated runtime files.
You can checkout the files with this command:
hg clone https://vim.googlecode.com/hg/ vim
For most machines you can install a Mercurial package that has the "hg"
command. More info here: http://mercurial.selenic.com/
The initial checkout takes a few minutes. After that updates should be
fast with:
hg pull
hg update
Let me know if something looks wrong. Once this is "approved" by
vim-dev I'll publish it to a larger audience.
--
You can't have everything. Where would you put it?
-- Steven Wright
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Gary Johnson
> On 2010-01-07, Bram Moolenaar wrote:
> >
> > I have setup a Mercurial repository. It contains the same files that
> > are in CVS, plus the updated runtime files.
>
> > Let me know if something looks wrong. Once this is "approved" by
> > vim-dev I'll publish it to a larger audience.
>
> I just set up repositories and built vim on two machines, one
> running Red Hat Enterprise Linux WS release 4 and hg version 1.0.2
> and another running Cygwin 1.5 with Windows XP and (Cygwin) hg
> version 1.3.1. Both installations went flawlessly. I will try with
> Cygwin 1.7 on another machine this evening.
It took a while to find and install all the right Cygwin development
libraries, but the Mercurial vim built fine on Cygwin 1.7 as well.
I compared the outputs of :version from the two Cygwin builds and
saw that the Cygwin 1.7 version includes the "-D_FORTIFY_SOURCE=1"
compilation flag whereas the Cygwin 1.5 version does not. This has
nothing to do with the repository, of course--I just thought it was
an odd difference.
Regards,
Gary
Bram Moolenaar
Chris Sutcliffe wrote:
> > I have setup a Mercurial repository. =A0It contains the same files that
> > are in CVS, plus the updated runtime files.
>
> <snip>
>
> > Let me know if something looks wrong. =A0Once this is "approved" by
> > vim-dev I'll publish it to a larger audience.
>
> Just curious, is the plan for this Mercurial repository to be the
> 'main' repository for Vim (like CVS is today)?
If all goes well I will make Mercurial the main (and only) repository
that I use. CVS slows me down. Mercurial is fast enough to also handle
runtime file updates.
Others can sync a CVS repository for those people who don't want to
install Mercurial. AFAIK Mercurial is available for all systems that
have CVS, thus it's only for people who can't install it for some
reason.
I'm not in a hurry though, I'll probably drop CVS only when 7.3 comes
out (whenever that will be).
--
From "know your smileys":
=):-) Uncle Sam
Mike Williams
Running Hg on XP Sp2 with Mercurial Distributed SCM (version
1.4.1+20091201). It would be a pain if a month old version causes problems.
I'll investigate a bit more my end. FTR a clone to a OBSD box had no
problems. I'll see what happens when I clone from that to my Windows box.
Mike
--
Prism: Place for light rays that commit minor refractions.
François Ingelrest
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
>
> You can checkout the files with this command:
>
> hg clone https://vim.googlecode.com/hg/ vim
>
> For most machines you can install a Mercurial package that has the "hg"
> command. More info here: http://mercurial.selenic.com/
>
> The initial checkout takes a few minutes. After that updates should be
> fast with:
>
> hg pull
> hg update
>
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
Cloned and compiled fine here on the latest Ubuntu (9.10). I'll go for
Mercurial now instead of CVS to update my Vim copy.
Mike Williams
Ok, that is SP3 and I have updated 1.4.2. Mea culpa, I had an old .ini
file lying around that enabled the clever encode/decode extension.
Remove that and it clones without warning. Why it didn't warn with my
repository I dunno.
Anyways, in case anyway else gets the warning this records the cause and
solution.
Otherwise working a charm.
TTFN
Xavier de Gaye
>
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
>
> You can checkout the files with this command:
>
> hg clone https://vim.googlecode.com/hg/ vim
>
I got this error when running the above command:
abort: Python support for SSL and HTTPS is not installed
Exception exceptions.AttributeError: "'httpsrepository' object has no
attribute 'urlopener'" in <bound method httpsrepository.__del__ of
<mercurial.httprepo.httpsrepository object at 0x7f60bd06e0d0>> ignored
But running ('http' instead of 'https') works just fine:
hg clone http://vim.googlecode.com/hg/ vim
Not tested: the pyOpenSSL package from
http://pyopenssl.sourceforge.net/ may be the missing package in my
setup.
For information, there is a very useful mercurial extension that
allows seeing the diffs between two revisions in vim with the DirDiff
plugin, see
http://mercurial.selenic.com/wiki/ExtdiffExtension
and run 'hg vim -r n1:n2'
Thanks for setting up a Vim Mercurial repository, this is a very nice
tool.
Xavier
Dominique Pellé
> For information, there is a very useful mercurial extension that
> allows seeing the diffs between two revisions in vim with the DirDiff
> plugin, see
> http://mercurial.selenic.com/wiki/ExtdiffExtension
> and run 'hg vim -r n1:n2'
>
> Thanks for setting up a Vim Mercurial repository, this is a very nice
> tool.
I'm using the vcscommand Vim plugin which provides
the ":VCSVimDiff" command (among other things) and which
works with Mercurial as well as with some other revision
control systems:
http://www.vim.org/scripts/script.php?script_id=90
It is well documented and has a good rating on www.vim.org.
I'm curious, is there any advantage in using the Mercurial
extension rather than the Vim plugin?
-- Dominique
Xavier de Gaye
>
> I'm curious, is there any advantage in using the Mercurial
> extension rather than the Vim plugin?
>
The Mercurial extension uses the DirDiff Vim plugin and operates over
the whole list of changed files. A window shows this list. You select
a file in this list with cursor keys and hit <Enter>. The plugin
displays a vimdiff of the changes for this file above the file list
window. DirDiff is also very useful by itself.
To install this Mercurial extension:
* install the DirDiff plugin:
http://www.vim.org/scripts/script.php?script_id=102
* add in your ~/.hgrc
[extensions]
hgext.extdiff =
[extdiff]
cmd.vimdiff = gvim
opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
* test it: modify few files and run
hg vimdiff
or shorter
hg vim
Xavier
Chris Sutcliffe
> If all goes well I will make Mercurial the main (and only) repository
> that I use. CVS slows me down. Mercurial is fast enough to also handle
> runtime file updates.
Excellent! I look forward to it!
> I'm not in a hurry though, I'll probably drop CVS only when 7.3 comes
> out (whenever that will be).
In the meantime, will you be updating the Mercurial repository as well
as CVS? I've noticed patch 328 is not in Mercurial yet, so I'm just
curious (I apologize if I'm jumping the gun a little bit here).
Cheers!
Chris Sutcliffe
> as CVS? I've noticed patch 328 is not in Mercurial yet, so I'm just
> curious (I apologize if I'm jumping the gun a little bit here).
It's there now...
Thank you!
Markus Heidelberg
>
> I have setup a Mercurial repository. It contains the same files that
> are in CVS, plus the updated runtime files.
What about these files, available via ftp, but not via hg?
runtime/getdos.aap
runtime/getunix.aap
runtime/main.aap
runtime/README.txt
runtime/spell/check/check_aa.aff
runtime/spell/check/check_aa.dic
runtime/spell/check/check_bb.aff
runtime/spell/check/check_bb.dic
runtime/spell/check/main.aap
runtime/spell/fixdup
runtime/spell/README_af.txt
runtime/spell/README_am.txt
runtime/spell/README_bg.txt
runtime/spell/README_ca.txt
runtime/spell/README_cs.txt
runtime/spell/README_cy.txt
runtime/spell/README_da.txt
runtime/spell/README_de.txt
runtime/spell/README_el.txt
runtime/spell/README_eo.txt
runtime/spell/README_es.txt
runtime/spell/README_fo.txt
runtime/spell/README_fr.txt
runtime/spell/README_ga.txt
runtime/spell/README_gd.txt
runtime/spell/README_gl.txt
runtime/spell/README_he.txt
runtime/spell/README_hr.txt
runtime/spell/README_hu.txt
runtime/spell/README_id.txt
runtime/spell/README_it.txt
runtime/spell/README_ku.txt
runtime/spell/README_la.txt
runtime/spell/README_lt.txt
runtime/spell/README_lv.txt
runtime/spell/README_mg.txt
runtime/spell/README_mi.txt
runtime/spell/README_ms.txt
runtime/spell/README_nb.txt
runtime/spell/README_nl.txt
runtime/spell/README_nn.txt
runtime/spell/README_ny.txt
runtime/spell/README_pl.txt
runtime/spell/README_pt.txt
runtime/spell/README_ro.txt
runtime/spell/README_ru.txt
runtime/spell/README_rw.txt
runtime/spell/README_sk.txt
runtime/spell/README_sl.txt
runtime/spell/README_sv.txt
runtime/spell/README_sw.txt
runtime/spell/README_th.txt
runtime/spell/README_tl.txt
runtime/spell/README_tn.txt
runtime/spell/README_uk.txt
runtime/spell/README_yi.txt
runtime/spell/README_zu.txt
runtime/spell/tet/main.aap
runtime/spell/tet/tet_ID.diff
src/po/main.aap
Chris Sutcliffe
>> are in CVS, plus the updated runtime files.
>
> What about these files, available via ftp, but not via hg?
The .aap files are a bit redundant given that all the code is in the
Mercurial repository anyway, aren't they?
Markus Heidelberg
> >> I have setup a Mercurial repository. It contains the same files that
> >> are in CVS, plus the updated runtime files.
> >
> > What about these files, available via ftp, but not via hg?
>
> The .aap files are a bit redundant given that all the code is in the
> Mercurial repository anyway, aren't they?
Not all .aap files are used for fetching files from Vim's ftp site.
However, this list was more or less generated automatically without any
judgement.
Markus
Bram Moolenaar
Markus Heidelberg wrote:
> Bram Moolenaar, 2010-01-07:
> >
> > I have setup a Mercurial repository. It contains the same files that
> > are in CVS, plus the updated runtime files.
>
> What about these files, available via ftp, but not via hg?
>
> runtime/getdos.aap
> runtime/getunix.aap
> runtime/main.aap
> runtime/README.txt
Specific for the ftp site.
> runtime/spell/check/check_aa.aff
> runtime/spell/check/check_aa.dic
> runtime/spell/check/check_bb.aff
> runtime/spell/check/check_bb.dic
> runtime/spell/check/main.aap
Need to be added
> runtime/spell/fixdup
obsolete
Only English spell files are included.
> runtime/spell/tet/main.aap
> runtime/spell/tet/tet_ID.diff
Need to be added
> src/po/main.aap
I don't see this file on the ftp site.
--
hundred-and-one symptoms of being an internet addict:
109. You actually read -- and enjoy -- lists like this.
Markus Heidelberg
>
> Markus Heidelberg wrote:
>
> > Bram Moolenaar, 2010-01-07:
> > >
> > > I have setup a Mercurial repository. It contains the same files that
> > > are in CVS, plus the updated runtime files.
> >
> > What about these files, available via ftp, but not via hg?
> >
I just noticed runtime/spell/yi/README.txt, which should be deleted from
the repository and the ftp server. The same file is available as
runtime/spell/README_yi.txt.
> > src/po/main.aap
>
> I don't see this file on the ftp site.
ftp://ftp.vim.org/pub/vim/messages/main.aap
Specific for the ftp site, to answer the question myself.
Bram Moolenaar
Markus Heidelberg wrote:
> > Only English spell files are included.
>
> I just noticed runtime/spell/yi/README.txt, which should be deleted from
> the repository and the ftp server. The same file is available as
> runtime/spell/README_yi.txt.
That is intentional. The other spell README files come from unpacking
the downloaded zip archive. This one was added from a different source.
It's a small file thus I don't think it's worth avoiding the duplication
by making the pattern complex.
Anyway, thanks for checking the list of files.
--
FIXME and XXX are two common keywords used to mark broken or incomplete code
not only since XXX as a sex reference would grab everbodys attention but
simply due to the fact that Vim would highlight these words.
-- Hendrik Scholz
Markus Heidelberg
>
> Let me know if something looks wrong. Once this is "approved" by
> vim-dev I'll publish it to a larger audience.
Is this the final Vim repository now or do you plan to rewrite it before
announcing it officially? Why don't you include the history (patch
descriptions) in it?
Markus
James Vega
Patch descriptions are included in the commits. This is more obvious
from the web interface, but you can see them with hg by giving “hg log”
the -v option. hg follows the convention where the first line of the
commit message is the short description and the remaining lines are the
long description. Only the former is displayed by “hg log” by default.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Markus Heidelberg
Ah, thanks for the explanation. I didn't have time to look into hg more
deeply and am used to see the complete message with "git log".
Now in this case the summary ("updated for version x.y.z") is pretty
meaningless and it would be better to include a real summary there.
And although still not knowing much about hg, I think it's possible with
it to include real authorship in the "user" part of the commit instead
of just adding the name to the "description" part.
Markus
James Vega
> James Vega, 2010-01-29:
> > On Fri, Jan 29, 2010 at 12:06:15AM +0100, Markus Heidelberg wrote:
> > > Bram Moolenaar, 2010-01-07:
> > > >
> > > > Let me know if something looks wrong. Once this is "approved" by
> > > > vim-dev I'll publish it to a larger audience.
> > >
> > > Is this the final Vim repository now or do you plan to rewrite it before
> > > announcing it officially? Why don't you include the history (patch
> > > descriptions) in it?
> >
> > Patch descriptions are included in the commits. This is more obvious
> > from the web interface, but you can see them with hg by giving “hg log”
> > the -v option. hg follows the convention where the first line of the
> > commit message is the short description and the remaining lines are the
> > long description. Only the former is displayed by “hg log” by default.
>
> Ah, thanks for the explanation. I didn't have time to look into hg more
> deeply and am used to see the complete message with "git log".
Understood. I had that same confusion initially. :)
> Now in this case the summary ("updated for version x.y.z") is pretty
> meaningless and it would be better to include a real summary there.
>
> And although still not knowing much about hg, I think it's possible with
> it to include real authorship in the "user" part of the commit instead
> of just adding the name to the "description" part.
I think this may come in time as people get used to the new workflow and
tools, but in the end that's up to Bram and how he wants to take
advantage of the tools.
hg doesn't seem to have the same capability as git where Author and
Committer are distinct concepts, but you can still specify a user to
make the commit as in order to maintain attribution.
Ben Schmidt
>> 'main' repository for Vim (like CVS is today)?
>
> If all goes well I will make Mercurial the main (and only) repository
> that I use. CVS slows me down. Mercurial is fast enough to also handle
> runtime file updates.
I'm loving it!
It sure beats what I have been doing, which is applying and committing
the patches in a Mercurial repository of my own and dealing with runtime
files separately.
Bram, I wonder whether you'd consider, to aid people who use git,
installing this Mercurial extension: <http://hg-git.github.com/>,
and setting up a hook so that when you push your changes to the public
hg repo, they also get pushed to a public git repo somewhere? The
benefit of doing it using that extension is that it converts to git
losslessly, so the two repos could interoperate. If desired at some
future stage, you could pull changes from others' git repositories just
as successfully as from hg ones.
Ulterior motive: It would make a lot of sense, and certainly make my
life easier, if the MacVim repository could be based on the Vim
repository. Of course, ideally I'd love to see MacVim using hg, too, but
with the help of that extension above, it could continue using git and
still use the official Vim repository, plus I could maintain my own hg
repository with the patches I regularly apply, test, and so on.
Bjorn, how does this sound to you? I know it could be a challenge to set
it up, particularly preserving old MacVim history and the way it
interacts with old Vim history, but would you be willing to pursue this?
I'm willing to help with that initial conversion.
Ben.
Jjgod Jiang
On Sat, Feb 13, 2010 at 12:05 PM, Ben Schmidt
<mail_ben...@yahoo.com.au> wrote:
> Ulterior motive: It would make a lot of sense, and certainly make my
> life easier, if the MacVim repository could be based on the Vim
> repository. Of course, ideally I'd love to see MacVim using hg, too, but
> with the help of that extension above, it could continue using git and
> still use the official Vim repository, plus I could maintain my own hg
> repository with the patches I regularly apply, test, and so on.
>
> Bjorn, how does this sound to you? I know it could be a challenge to set
> it up, particularly preserving old MacVim history and the way it
> interacts with old Vim history, but would you be willing to pursue this?
> I'm willing to help with that initial conversion.
I am also interested in maintaining a git repository based on vim hg repo,
either directly or indirectly. Currently both mine (vim-cocoa) and MacVim
repo are based on the Subversion repo at sf.net, which is synced manually
with git-svn, so I am also curious about the technical approach to switch
from git-svn to this hg or git repo set up by upstream.
- Jiang
mobi phil
populated for similar reasons....
mobiphil
http://mobiphil.com
2010/2/13 Jjgod Jiang <gzj...@gmail.com>:
> --
> You received this message from the "vim_dev" maillist.
> For more information, visit http://www.vim.org/maillist.php
>
--
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
bjorn.winckler
>
> Bram, I wonder whether you'd consider, to aid people who use git,
> installing this Mercurial extension: <http://hg-git.github.com/>,
> and setting up a hook so that when you push your changes to the public
> hg repo, they also get pushed to a public git repo somewhere? The
> benefit of doing it using that extension is that it converts to git
> losslessly, so the two repos could interoperate. If desired at some
> future stage, you could pull changes from others' git repositories just
> as successfully as from hg ones.
>
> Ulterior motive: It would make a lot of sense, and certainly make my
> life easier, if the MacVim repository could be based on the Vim
> repository. Of course, ideally I'd love to see MacVim using hg, too, but
> with the help of that extension above, it could continue using git and
> still use the official Vim repository, plus I could maintain my own hg
> repository with the patches I regularly apply, test, and so on.
>
> Bjorn, how does this sound to you? I know it could be a challenge to set
> it up, particularly preserving old MacVim history and the way it
> interacts with old Vim history, but would you be willing to pursue this?
> I'm willing to help with that initial conversion.
I'm waiting until things "settle". If Bram decides to continue with
the hg repo I was considering switching to hg for MacVim as well. For
me it makes more sense to just follow Bram's lead -- I only started
with the git repo because of the lack of other options at that time (I
wanted to use _some_ distributed vcs but I don't really care that much
about which particular one to use).
Importing the current MacVim history to hg is something I don't look
forward to however, I'll take any help I can get with this task. If
it is possible to simply change the upstream source for my repo to the
hg repo (instead of the svn repo that I currently pull from) and stick
with git, then I might consider that instead. As I said though: I'm
not in a hurry to change the current repo.
Björn
Bram Moolenaar
Ben Schmidt wrote:
I have no idea how reliable this is. I do know that pushes to Mercurial
fail sometimes, e.g., when the server is read-only for a little while.
If I also have to handle failures in git it may become a little bit
complicated.
Isn't it possible for a git user to pull from the Mercurial repository?
No push is needed (or desired).
--
hundred-and-one symptoms of being an internet addict:
230. You spend your Friday nights typing away at your keyboard
Ben Schmidt
>> installing this Mercurial extension:<http://hg-git.github.com/>,
>> and setting up a hook so that when you push your changes to the public
>> hg repo, they also get pushed to a public git repo somewhere? The
>> benefit of doing it using that extension is that it converts to git
>> losslessly, so the two repos could interoperate. If desired at some
>> future stage, you could pull changes from others' git repositories just
>> as successfully as from hg ones.
>>
>
> fail sometimes, e.g., when the server is read-only for a little while.
> If I also have to handle failures in git it may become a little bit
> complicated.
>
> Isn't it possible for a git user to pull from the Mercurial repository?
> No push is needed (or desired).
As far as I know, the only way to do hg-git bidirectional conversion
losslessly is using the Mercurial extension of that name. So Mercurial
users can use Git repositories losslessly, but Git users can't do the
same for Mercurial ones. They can do lossy conversions, but of course
that is no good once they want to collaborate.
Now, there's no reason I, or anyone else, couldn't pull from the hg
repo and push to a public git repo. But for convenience, and for
efficiently propagating changes, it would be better if the push, or at
least a notification to do so, could come from you, rather than playing
the polling game. Not necessary, but could be a nice thing to do.
I also don't have enough experience to know how reliable it is.
Cheers,
Ben.
Ben Schmidt
>> Ulterior motive: It would make a lot of sense, and certainly make my
>> life easier, if the MacVim repository could be based on the Vim
>> repository. Of course, ideally I'd love to see MacVim using hg, too, but
>> with the help of that extension above, it could continue using git and
>> still use the official Vim repository, plus I could maintain my own hg
>> repository with the patches I regularly apply, test, and so on.
>>
>> Bjorn, how does this sound to you? I know it could be a challenge to set
>> it up, particularly preserving old MacVim history and the way it
>> interacts with old Vim history, but would you be willing to pursue this?
>> I'm willing to help with that initial conversion.
Bjorn wrote:
> I'm waiting until things "settle".
I agree this is wise. I think we need only wait until we're sure that
Mercurial will continue, i.e. once vim_dev have tried it out a bit more
thoroughly and Bram decides to publish its existence more widely. We
needn't wait until CVS is dropped.
Bjorn wrote:
> If Bram decides to continue with the hg repo I was considering
> switching to hg for MacVim as well. For me it makes more sense to
> just follow Bram's lead -- I only started with the git repo because of
> the lack of other options at that time (I wanted to use _some_
> distributed vcs but I don't really care that much about which
> particular one to use).
That would suit me!
Bjorn wrote:
> Importing the current MacVim history to hg is something I don't look
> forward to however, I'll take any help I can get with this task. If
> it is possible to simply change the upstream source for my repo to the
> hg repo (instead of the svn repo that I currently pull from) and stick
> with git, then I might consider that instead. As I said though: I'm
> not in a hurry to change the current repo.
It wouldn't be as simple as changing the upstream repo. The repo would
need to be converted/rebuilt.
Jiang wrote:
> I am also interested in maintaining a git repository based on vim hg
> repo, either directly or indirectly. Currently both mine (vim-cocoa)
> and MacVim repo are based on the Subversion repo at sf.net, which is
> synced manually with git-svn, so I am also curious about the technical
> approach to switch from git-svn to this hg or git repo set up by
> upstream.
I haven't searched the web for potential solutions to this problem, yet,
but was thinking something along these lines would work if nothing else:
- get an hg version of the MacVim git repo
- clone the Vim hg repo
- initialise some kind of table to map equivalent revisions in the two
repos
- identify (using a script somehow, most likely) revisions in the two
repos that are nominally equivalent, i.e. vim upstream revisions that
are the same patchlevel
- possibly identify runtime file updates somehow
- for each unidentified revision in the MacVim repo:
- check out a working copy
- find the parents
- using the table, set the parents of the working copy of the Vim
repo to the equivalent revisions
- copy the contents of the MacVim working copy to the Vim working
copy
- check in the Vim working copy with the appropriate commit message
from the MacVim revision
- add the new changeset to the map of equivalent revisions
- tag appropriately
- push losslessly to a git repo if desired
This approach I think has a few advantages
- by copying working copies rather than playing games with diffs, we are
assured that the revisions are content-wise the same in the new repo
as the MacVim repo
- MacVim revisions that aren't merges with Vim revisions will have
different hashes, but the same diffs, so MacVim history is essentially
maintained
- Vim history is unaltered from the official repo
There are some issues that require further thought or are a bit unknown
- revisions that are Vim-MacVim merges could end up with a bunch of
changes that shouldn't really be there, particulary regarding runtime
files, if the MacVim repo's idea about a particular patchlevel is
different to the Vim repo's idea about the same
- any named branches, octopus merges, or other somewhat git-specific
things could pose challenges
- how to deal with runtime files needs to be considered; I suspect
eliminating them from the MacVim history, except for tagged snapshots,
would be a sufficient solution, and a good compromise between having a
lot of spurious changes bloating the repo size, but keeping accurate
history; after all, Vim is often run with different runtime files to
its source code, and does just fine on the whole
Naturally, I'm open to comments on this, or to someone else more in the
know doing it rather than me! I am willing to put time into something
like this, though; I feel it would help both the community and me.
Ben.