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.