What should we do if the Mercurial source server is retired ?
36 views
Skip to first unread message
Tony Mechelynck
Nov 20, 2024, 4:27:43 AM11/20/24
to Christian Brabandt, vim_dev
The "official" solution, if the Mercurial server is retired forever,
is to use git instead, but to at least one of us (me) and possibly
more, git is so foreign that we would rather explore all other
possible solutions before resorting to it. This message is written by
and for this kind of user.
Solution 1 : Remain with the last Vim executables we compiled from the
supposedly defunct Mercurial sources.
-- This seems to be a valid stopgap measure as long as other measures
(see below) provide no higher patchlevel of Vim ; but it is not usable
forever.
Solution 2 : Get our Vim executables elsewhere, for instance from a
Linux distribution or from a precompiled MacVim or Vim-for-Windows
distribution.
-- These executables are never the latest of the newest, and they are
almost never configured according to the set of features we would have
chosen if we had configured and compiled our own Vim executables, so
if we do that we will forever regret that we can't configure our own
Vim anymore : we will forever feel like second-rank citizens compared
to what we used to be. So it is a valid solution but never fully
satisfying.
Solution 3 : Enable the "gif" extension in Mercurial, learn how to use
it, and use it to make the official git repository appear like a
Mercurial repository from where we sit.
-- The problem here is "learn how to use it" : indeed, the online
Mercurial help about the git extension is practically nil : here it is
:
hg config extensions.git= help git
git extension - grant Mercurial the ability to operate on Git
repositories. (EXPERIMENTAL)
This is currently super experimental. It probably will consume
your firstborn a la Rumpelstiltskin, etc.
no commands defined
That's all. (I've added indentation to separate the lines of output
even if linebreaks are added in e-mail transit.) To me, such a
so-called "help" is actually no help at all, so I admire Christian all
the more for having succeeded to actually bring a working git-to-hg
server up and running, even if it is now defunct, and I hope it isn't.
If I am to someday understand how to use Mercurial on a git server
(and make no mistake : I hope I someday will) I think I will have to
meekly and politely ask Christian to write a "real" HowTo page that
could at least compare with, if not necessarily attain the level of
excellence of, what we have become accustomed to by perusing the Vim
help. I know this is a tall order, and I don't know if Christian will
have the time and staying power to provide such a HowTo to make others
benefit from his experiences ; but AFAICT that's the only exit I see
from this apparently dead-end situation, and I don't like it.
Solution 4 : Convince Christian (or someone) to move the Mercurial
server to some place where it will be available again, with all the
desired throughput.
-- The problem with this is that it is not in everyone's hands : my
ISP has (some years ago already) shut down all the access I had to a
user website, so even if I had the necessary knowledge to set up a
public git-to-Mercurial server (which I alas don't), I don't have the
means. I can of course argue in favour of such a solution, but I
cannot "put my hands where my mouth is" otherwise I would already have
started doing it. Christian obviously has the necessary knowledge ;
maybe someone else has it too ; I don't. Please anyone, if you have
both the knowledge and the means, please consider setting up a
Mercurial server somewhere accessible, so for the rest of us it will
just be a matter of adjusting the source aliases in our Mercurial
client's per-repository configuration for Vim, which is easy as a
breeze.
Best regards,
Tony.
is to use git instead, but to at least one of us (me) and possibly
more, git is so foreign that we would rather explore all other
possible solutions before resorting to it. This message is written by
and for this kind of user.
Solution 1 : Remain with the last Vim executables we compiled from the
supposedly defunct Mercurial sources.
-- This seems to be a valid stopgap measure as long as other measures
(see below) provide no higher patchlevel of Vim ; but it is not usable
forever.
Solution 2 : Get our Vim executables elsewhere, for instance from a
Linux distribution or from a precompiled MacVim or Vim-for-Windows
distribution.
-- These executables are never the latest of the newest, and they are
almost never configured according to the set of features we would have
chosen if we had configured and compiled our own Vim executables, so
if we do that we will forever regret that we can't configure our own
Vim anymore : we will forever feel like second-rank citizens compared
to what we used to be. So it is a valid solution but never fully
satisfying.
Solution 3 : Enable the "gif" extension in Mercurial, learn how to use
it, and use it to make the official git repository appear like a
Mercurial repository from where we sit.
-- The problem here is "learn how to use it" : indeed, the online
Mercurial help about the git extension is practically nil : here it is
:
hg config extensions.git= help git
git extension - grant Mercurial the ability to operate on Git
repositories. (EXPERIMENTAL)
This is currently super experimental. It probably will consume
your firstborn a la Rumpelstiltskin, etc.
no commands defined
That's all. (I've added indentation to separate the lines of output
even if linebreaks are added in e-mail transit.) To me, such a
so-called "help" is actually no help at all, so I admire Christian all
the more for having succeeded to actually bring a working git-to-hg
server up and running, even if it is now defunct, and I hope it isn't.
If I am to someday understand how to use Mercurial on a git server
(and make no mistake : I hope I someday will) I think I will have to
meekly and politely ask Christian to write a "real" HowTo page that
could at least compare with, if not necessarily attain the level of
excellence of, what we have become accustomed to by perusing the Vim
help. I know this is a tall order, and I don't know if Christian will
have the time and staying power to provide such a HowTo to make others
benefit from his experiences ; but AFAICT that's the only exit I see
from this apparently dead-end situation, and I don't like it.
Solution 4 : Convince Christian (or someone) to move the Mercurial
server to some place where it will be available again, with all the
desired throughput.
-- The problem with this is that it is not in everyone's hands : my
ISP has (some years ago already) shut down all the access I had to a
user website, so even if I had the necessary knowledge to set up a
public git-to-Mercurial server (which I alas don't), I don't have the
means. I can of course argue in favour of such a solution, but I
cannot "put my hands where my mouth is" otherwise I would already have
started doing it. Christian obviously has the necessary knowledge ;
maybe someone else has it too ; I don't. Please anyone, if you have
both the knowledge and the means, please consider setting up a
Mercurial server somewhere accessible, so for the rest of us it will
just be a matter of adjusting the source aliases in our Mercurial
client's per-repository configuration for Vim, which is easy as a
breeze.
Best regards,
Tony.
Marvin Renich
Nov 20, 2024, 1:48:16 PM11/20/24
to vim...@googlegroups.com
* Tony Mechelynck <antoine.m...@gmail.com> [241120 04:27]:
> Solution 3 : Enable the "gif" extension in Mercurial, learn how to use
> it, and use it to make the official git repository appear like a
> Mercurial repository from where we sit.
> -- The problem here is "learn how to use it" : indeed, the online
> Mercurial help about the git extension is practically nil : here it is
> :
> hg config extensions.git= help git
> git extension - grant Mercurial the ability to operate on Git
> repositories. (EXPERIMENTAL)
> This is currently super experimental. It probably will consume
> your firstborn a la Rumpelstiltskin, etc.
> no commands defined
> That's all. (I've added indentation to separate the lines of output
> even if linebreaks are added in e-mail transit.) To me, such a
I have, in the past, used the hggit extension
(https://hg-git.github.io/), rather than the git extension. It is
packaged in Debian as mercurial-git. To use it, simply add
«[extensions] hggit = » to your .hgrc, then use git URLs to clone the
repo, e.g. «hg clone git+https://github.com/vim/vim.git». Other than
that, you simply use hg as you normally would. And, it has help.
Note that the instructions on the website say to also add
hgext.bookmarks= to your .hgrc, but if you read more carefully, it says
this is only needed for hg versions prior to 1.7, which is _very_ old.
I didn't add this and it seems to work fine.
I just tried the above clone in a fresh VM. It works fine, but it takes
a while to clone, as there are more than 20,000 commits. There is a
progress bar during the download, but when all the commits are
downloaded, there is a long pause without any feedback while the
extension converts the git commits to mercurial.
...Marvin
> The "official" solution, if the Mercurial server is retired forever,
> is to use git instead, but to at least one of us (me) and possibly
> more, git is so foreign that we would rather explore all other
> possible solutions before resorting to it. This message is written by
> and for this kind of user.
[snip]
> is to use git instead, but to at least one of us (me) and possibly
> more, git is so foreign that we would rather explore all other
> possible solutions before resorting to it. This message is written by
> and for this kind of user.
> Solution 3 : Enable the "gif" extension in Mercurial, learn how to use
> it, and use it to make the official git repository appear like a
> Mercurial repository from where we sit.
> -- The problem here is "learn how to use it" : indeed, the online
> Mercurial help about the git extension is practically nil : here it is
> :
> hg config extensions.git= help git
> git extension - grant Mercurial the ability to operate on Git
> repositories. (EXPERIMENTAL)
> This is currently super experimental. It probably will consume
> your firstborn a la Rumpelstiltskin, etc.
> no commands defined
> That's all. (I've added indentation to separate the lines of output
> even if linebreaks are added in e-mail transit.) To me, such a
(https://hg-git.github.io/), rather than the git extension. It is
packaged in Debian as mercurial-git. To use it, simply add
«[extensions] hggit = » to your .hgrc, then use git URLs to clone the
repo, e.g. «hg clone git+https://github.com/vim/vim.git». Other than
that, you simply use hg as you normally would. And, it has help.
Note that the instructions on the website say to also add
hgext.bookmarks= to your .hgrc, but if you read more carefully, it says
this is only needed for hg versions prior to 1.7, which is _very_ old.
I didn't add this and it seems to work fine.
I just tried the above clone in a fresh VM. It works fine, but it takes
a while to clone, as there are more than 20,000 commits. There is a
progress bar during the download, but when all the commits are
downloaded, there is a long pause without any feedback while the
extension converts the git commits to mercurial.
...Marvin
Tony Mechelynck
Nov 21, 2024, 12:10:11 AM11/21/24
to vim...@googlegroups.com
hggit package ; so I installed it but didn't yet enable it. Strangely
as it may seem, Mercurial regards it as "external" but doesn't need to
be told where it is :
linux-tuxedo:~/.build/vim/vim-hg # hg --config extensions.hggit= version -v
Mercurial Distributed SCM (version 6.8.2)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2024 Olivia Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Enabled extensions:
churn internal
fetch internal
hggit external 1.1.3 (dulwich 0.22.1)
mq internal
pager internal
strip internal
linux-tuxedo:~/.build/vim/vim-hg #
The part I don't understand in the hggit help is the need to download
a separate git clone on my hard drive outside my Mercurial repository
of Vim, even though the latter includes the .gitignore and other files
needed by git but not by Mercurial. (It also includes, of course, the
.hgignore and other files needed by Mercurial but not by git.) I would
have thought that, let's say, after having set the "default" remote
source to the proper git: URL for the Vim server on github, I could
use "hg in" and "hg fetch --switch-parent" on my existing Mercurial
repository as usual and that it would list or pull (respectively) any
new changesets available on github, converting them to proper
Mercurial changesets as it went and committing them as descendants
from the existing ones (downloaded from Christian's Mercurial server
and before that from Bram's), without the need to rebuild the whole
stuff from scratch.
I have a hint that the authors of the hggit help are interested mostly
in "pushing" to git while I am interested only and exclusively in
"pulling" from git in order to "make" from the source thus downloaded
successively better Vim executables configured to my will and wish. If
I ever feel the need to contribute changes to the source and the
runtime files, I will, like in the past, write them as local mq
patches and send them to the list in "unified git diff" format as
produced by Mercurial even without the hggit extension.
Best regards,
Tony.
Marvin Renich
Nov 21, 2024, 9:33:09 AM11/21/24
to vim...@googlegroups.com
* Tony Mechelynck <antoine.m...@gmail.com> [241121 00:10]:
hadn't specified --config... it would not have found the extension. You
only need to specify paths for extensions that are not in your Python
module path, but the extension name must be mentioned in your .hgrc file
to be found.
> The part I don't understand in the hggit help is the need to download
> a separate git clone on my hard drive outside my Mercurial repository
> of Vim, even though the latter includes the .gitignore and other files
> needed by git but not by Mercurial. (It also includes, of course, the
> .hgignore and other files needed by Mercurial but not by git.) I would
> have thought that, let's say, after having set the "default" remote
> source to the proper git: URL for the Vim server on github, I could
> use "hg in" and "hg fetch --switch-parent" on my existing Mercurial
> repository as usual and that it would list or pull (respectively) any
> new changesets available on github, converting them to proper
> Mercurial changesets as it went and committing them as descendants
> from the existing ones (downloaded from Christian's Mercurial server
> and before that from Bram's), without the need to rebuild the whole
> stuff from scratch.
It puts the Git clone in the directory .hg/git in your repo. When
pulling from a Git repo, it must be able to match Mercurial commits with
corresponding Git commits. Because the Git hashes are different from
the Mercurial hashes, it does this by comparing the contents of the
commits, so it must have all of the Git commits. Once you have pulled
from (or cloned) a Git repo, subsequent pulls will only have to download
new commits. This is the same as with a remote Mercurial repo, but the
code used to download and compare Git commits with the existing
Mercurial commits is much slower than either a "git pull" or "hg pull"
from a native repo.
You will find a file .hg/git-mapfile with a table of hg<->git commit
hashes. Also, Git and Mercurial have some different philosophies,
especially regarding tags. Mercurial tags are stored as commits, while
Git tags are metadata in the .git directory, so the correspondence
between commits is not one-to-one.
> I have a hint that the authors of the hggit help are interested mostly
> in "pushing" to git while I am interested only and exclusively in
> "pulling" from git in order to "make" from the source thus downloaded
> successively better Vim executables configured to my will and wish.
I don't think this is true. I think it is just the initial use of clone
or pull that is taking so long that is giving you this impression.
> If
> I ever feel the need to contribute changes to the source and the
> runtime files, I will, like in the past, write them as local mq
> patches and send them to the list in "unified git diff" format as
> produced by Mercurial even without the hggit extension.
>
> Best regards,
> Tony.
...Marvin
> On Wed, Nov 20, 2024 at 7:48 PM Marvin Renich <mr...@renich.org> wrote:
> > I have, in the past, used the hggit extension
> > (https://hg-git.github.io/), rather than the git extension. It is
> > packaged in Debian as mercurial-git. To use it, simply add
> > «[extensions] hggit = » to your .hgrc, then use git URLs to clone the
> > repo, e.g. «hg clone git+https://github.com/vim/vim.git». Other than
> > that, you simply use hg as you normally would. And, it has help.
> >
> > Note that the instructions on the website say to also add
> > hgext.bookmarks= to your .hgrc, but if you read more carefully, it says
> > this is only needed for hg versions prior to 1.7, which is _very_ old.
> > I didn't add this and it seems to work fine.
> >
> > I just tried the above clone in a fresh VM. It works fine, but it takes
> > a while to clone, as there are more than 20,000 commits. There is a
> > progress bar during the download, but when all the commits are
> > downloaded, there is a long pause without any feedback while the
> > extension converts the git commits to mercurial.
>
> > I have, in the past, used the hggit extension
> > (https://hg-git.github.io/), rather than the git extension. It is
> > packaged in Debian as mercurial-git. To use it, simply add
> > «[extensions] hggit = » to your .hgrc, then use git URLs to clone the
> > repo, e.g. «hg clone git+https://github.com/vim/vim.git». Other than
> > that, you simply use hg as you normally would. And, it has help.
> >
> > Note that the instructions on the website say to also add
> > hgext.bookmarks= to your .hgrc, but if you read more carefully, it says
> > this is only needed for hg versions prior to 1.7, which is _very_ old.
> > I didn't add this and it seems to work fine.
> >
> > I just tried the above clone in a fresh VM. It works fine, but it takes
> > a while to clone, as there are more than 20,000 commits. There is a
> > progress bar during the download, but when all the commits are
> > downloaded, there is a long pause without any feedback while the
> > extension converts the git commits to mercurial.
>
> Since I posted the above, I found that my Linux distro includes an
> hggit package ; so I installed it but didn't yet enable it. Strangely
> as it may seem, Mercurial regards it as "external" but doesn't need to
> be told where it is :
>
> linux-tuxedo:~/.build/vim/vim-hg # hg --config extensions.hggit= version -v
By default, Mercurial looks for extensions in the Python path. If you
> hggit package ; so I installed it but didn't yet enable it. Strangely
> as it may seem, Mercurial regards it as "external" but doesn't need to
> be told where it is :
>
> linux-tuxedo:~/.build/vim/vim-hg # hg --config extensions.hggit= version -v
hadn't specified --config... it would not have found the extension. You
only need to specify paths for extensions that are not in your Python
module path, but the extension name must be mentioned in your .hgrc file
to be found.
> The part I don't understand in the hggit help is the need to download
> a separate git clone on my hard drive outside my Mercurial repository
> of Vim, even though the latter includes the .gitignore and other files
> needed by git but not by Mercurial. (It also includes, of course, the
> .hgignore and other files needed by Mercurial but not by git.) I would
> have thought that, let's say, after having set the "default" remote
> source to the proper git: URL for the Vim server on github, I could
> use "hg in" and "hg fetch --switch-parent" on my existing Mercurial
> repository as usual and that it would list or pull (respectively) any
> new changesets available on github, converting them to proper
> Mercurial changesets as it went and committing them as descendants
> from the existing ones (downloaded from Christian's Mercurial server
> and before that from Bram's), without the need to rebuild the whole
> stuff from scratch.
pulling from a Git repo, it must be able to match Mercurial commits with
corresponding Git commits. Because the Git hashes are different from
the Mercurial hashes, it does this by comparing the contents of the
commits, so it must have all of the Git commits. Once you have pulled
from (or cloned) a Git repo, subsequent pulls will only have to download
new commits. This is the same as with a remote Mercurial repo, but the
code used to download and compare Git commits with the existing
Mercurial commits is much slower than either a "git pull" or "hg pull"
from a native repo.
You will find a file .hg/git-mapfile with a table of hg<->git commit
hashes. Also, Git and Mercurial have some different philosophies,
especially regarding tags. Mercurial tags are stored as commits, while
Git tags are metadata in the .git directory, so the correspondence
between commits is not one-to-one.
> I have a hint that the authors of the hggit help are interested mostly
> in "pushing" to git while I am interested only and exclusively in
> "pulling" from git in order to "make" from the source thus downloaded
> successively better Vim executables configured to my will and wish.
or pull that is taking so long that is giving you this impression.
> If
> I ever feel the need to contribute changes to the source and the
> runtime files, I will, like in the past, write them as local mq
> patches and send them to the list in "unified git diff" format as
> produced by Mercurial even without the hggit extension.
>
> Best regards,
> Tony.
Tony Mechelynck
Nov 21, 2024, 11:20:45 AM11/21/24
to vim...@googlegroups.com
extensions.convert= help convert". What it says is more similar to
what I see in the changesets pulled from Christian's Mercurial server
but it is seems not to be identical.
I guess that for the time being I'll keep my own-compiled Vim "frozen"
at 9.1.873 (which is higher than the 9.1.836 currently available from
my Linux distro anyway) and "wait and see" how circumstances evolve
with time.
Best regards,
Tony.
Reply all
Reply to author
Forward
0 new messages