On Mon, Aug 28, 2023 at 9:11 PM Christian Brabandt <c...@256bit.org> wrote:
>
>
> On Mo, 28 Aug 2023, Tony Mechelynck wrote:
>
> > Christian, do you have any recommendations for someone who would want
> > to continue porting the changes from git to Mercurial if you ever
> > decide to close your own Mercurial mirror, or is it not worth the
> > trouble unless this new Mercurial mirror is made public (for instance
> > by maintaining a git mirror, exporting each patch as a set of diffs,
> > and importing that to a Mercurial clone) ? (I used to have a user site
> > but my ISP has closed it for no other reason than "if you want to
> > continue having a user site after DD/MM/YYYY, get into contact with us
> > before that date and an engineer of ours will build it for you". — I
> > was perfectly happy with building it slowly but surely by FTP and I
> > prefer to mind my own business, thank you.)
>
> For a recommendation you mean what is required to set this up manually?

Yes, that's what I meant, as well as anything you might have about
warning me (or anyone) about any pitfalls you might have encountered
in the past and how to avoid them.
>
> It's currently a self-written shell script (attached)¹, that pulls the
> git mirror every 15 minutes and pushes each commit as new change to the
> mercurial repository. It used to work flawlessly (until I recently added
> pushing out mails). I reverted that part for now, let's see how well
> this works in the future. If it keeps running as good as it was in the
> past and doesn't cause any more issues, then it will just keep being
> updated.

Well, currently I run "hg in" approximately once an hour when I'm at
the computer, or not at all when I'm not; and when there is something
new, I update my clone then I compile, as a sanity test, five
different versions of Vim (they used to be huge, big, normal, small
and tiny; now that Bram has retired two of these they are huge with
GTK3 and as many features as I can, huge with GTK3 without interpreted
languages, normal with Motif and +sodium, tiny with Motif and tiny
with no GUI Sizes between 4.2 and 1.5 GB).

Thanks a lot for that script, I saved it where it won't get lost. I
think that I could understand it better with just a little study but
that it isn't really out of my mental reach.

A few days ago there were multiple heads in the "default" branch, as I
told you I think I found out how to make my clone easily usable and (I
think) compatible with your @256bit.org repo, in any case later
updates have come in with no problems. I ran "hg diff" between the
remote and the local and the only differences it found are the ones I
intentionally added in src/feature.h (add +xterm_save for which there
is no configure argument AFAIK) and in .hgignore (add runtime/doc/tags
at the very bottom, which means I have to either remove that file by
hand if there comes a change to it, or run manually "hg merge"
followed by "hg commit" if I forget).
>
> There is currently the following line commented out:
> ,----
> |         # echo "$patch" | hg import --bypass -
> `----
> Perhaps there were some issues with backslashes or other strange stuff,
> that echo interpreted differently and caused those problems, did not
> want to experiment with this to cause more issues for users.
>
>
> ¹) I thought about adding helper scripts as an additional repository
> below the vim organization, so that basically everybody can run this on
> their own and does no longer require a central bridge. Also, it could be
> used for some help scripts (e.g. those famous scripts Bram used to
> verify runtime files updates).

It would be an idea, but then they would have to be documented, at
least with a lot of comments in the text (more than you would need
yourself) and maybe it would be too much toil for their use.
>
> Best,
> Christian

Best regards,
Tony.
> --
> What happened last night can happen again.

Yeah, that reminds me of the warning displayed in France below the
double St-Andrews cross at level crossings with double-track railway
lines:
"Un train peut en cacher un autre"
(i.e. One train can hide another one)

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAJkCKXv2KLsDkBeZtW2nNE98kyqQYL6m4WFd4ss3yg00LvygHw%40mail.gmail.com.

Raspunde prin e-mail lui