[-- Attachment #1: Type: text/plain, Size: 754 bytes --] Hi everyone, Just an observation. Since I submitted a question on the mirrors back in January I keep a copy of all 3 repositories. I manually run a script that updates all of them from time to time. What I have noticed is(at times) gitlab may take a couple of days(maybe more) to be in sync with the other two. Most of the time all three seem to stay in sync. As an example for the last couple of "my day times": sourceforge: zsh-5.9-88-g6d49734d4 github: zsh-5.9-88-g6d49734d4 gitlab: zsh-5.9-85-g67d4bf5bb Don't know if this is an issue or a procedural thing. Just my observation. Thought I would let you know in case there may be an issue. If this is normal, sorry for the noise. Again, thanks to all for your work on zsh. Regards, Jim Murphy [-- Attachment #2: Type: text/html, Size: 1041 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --] Ignore last message. Sorry for the noise. A new clone is fine. Started working with worktrees and am guessing my local repository is in some state that I haven't figured out yet. Something else I need to learn about git. Again, sorry for the noise. Jim On Thu, Dec 15, 2022 at 7:47 AM Jim <linux.tech.guy@gmail.com> wrote: > Hi everyone, > > Just an observation. Since I submitted a question on the mirrors back in > January > I keep a copy of all 3 repositories. I manually run a script that updates > all of them > from time to time. What I have noticed is(at times) gitlab may take a > couple of > days(maybe more) to be in sync with the other two. Most of the time all > three seem > to stay in sync. As an example for the last couple of "my day times": > > sourceforge: zsh-5.9-88-g6d49734d4 > github: zsh-5.9-88-g6d49734d4 > gitlab: zsh-5.9-85-g67d4bf5bb > > Don't know if this is an issue or a procedural thing. Just my observation. > Thought I would let you know in case there may be an issue. If this is > normal, > sorry for the noise. > > Again, thanks to all for your work on zsh. > > Regards, > > Jim Murphy > [-- Attachment #2: Type: text/html, Size: 1722 bytes --]
Actually, I do wonder why we don't use GitLab's built-in mirroring
thing. Perhaps in order to allow people to submit completion patches to
either GitHub or GitLab at their choice?
Also, while looking into your report I ran into a GitLab message that I
wouldn't have seen otherwise, so, thanks.
Daniel
Jim wrote on Thu, Dec 15, 2022 at 13:01:57 -0600:
> Ignore last message. Sorry for the noise. A new clone is fine. Started
> working with
> worktrees and am guessing my local repository is in some state that I
> haven't figured
> out yet. Something else I need to learn about git. Again, sorry for the
> noise.
>
> Jim
>
> On Thu, Dec 15, 2022 at 7:47 AM Jim <linux.tech.guy@gmail.com> wrote:
>
> > Hi everyone,
> >
> > Just an observation. Since I submitted a question on the mirrors back in
> > January
> > I keep a copy of all 3 repositories. I manually run a script that updates
> > all of them
> > from time to time. What I have noticed is(at times) gitlab may take a
> > couple of
> > days(maybe more) to be in sync with the other two. Most of the time all
> > three seem
> > to stay in sync. As an example for the last couple of "my day times":
> >
> > sourceforge: zsh-5.9-88-g6d49734d4
> > github: zsh-5.9-88-g6d49734d4
> > gitlab: zsh-5.9-85-g67d4bf5bb
> >
> > Don't know if this is an issue or a procedural thing. Just my observation.
> > Thought I would let you know in case there may be an issue. If this is
> > normal,
> > sorry for the noise.
> >
> > Again, thanks to all for your work on zsh.
> >
> > Regards,
> >
> > Jim Murphy
> >
[-- Attachment #1.1: Type: text/plain, Size: 1489 bytes --] Hi again, I'm beginning to sound like a broken record. That's what happens when I try doing things after getting a flu and covid shots(side effects: fever - chills - aches - sleepy). Way better than the flu or covid. :-) Anyway, to test, started a new terminal and shell and ran the attached function. The function clones all three repositories in the /tmp directory. The results are as follows: github URL: https://github.com/zsh-users/zsh.git LogFileName: /tmp/zsh_git_repos/github/clone_error_log return code: 0 zsh-5.9-91-g1de8baded gitlab URL: https://gitlab.com/zsh-org/zsh.git LogFileName: /tmp/zsh_git_repos/gitlab/clone_error_log return code: 0 zsh-5.9-85-g67d4bf5bb sourceforge URL: git://git.code.sf.net/p/zsh/code LogFileName: /tmp/zsh_git_repos/sourceforge/clone_error_log return code: 0 zsh-5.9-91-g1de8baded As you can see from the output of the git describe command, gitlab does not give the same result as the other sites. git log starts with: commit 67d4bf5bb936a5b95160410b4790f2bf4113c75f (HEAD -> master, origin/master, origin/HEAD) Author: Peter Stephenson <p.stephenson@samsung.com> Date: Mon Dec 12 10:30:13 2022 +0000 51134: ! return doesn't change the return status So unless I'm missing something, or still suffering the side effects of the flu and covid shots, it appears to indicate that gitlab isn't up to date. I would appreciate it if someone could run the function and verify if they get the same results. Thanks and Regards, Jim [-- Attachment #1.2: Type: text/html, Size: 2152 bytes --] [-- Attachment #2: clone_zsh_repos --] [-- Type: application/octet-stream, Size: 797 bytes --] clone_zsh_repos () { emulate -L zsh setopt extendedglob local E N P R RDN V local -a D Rs URLs D=( '' '' zsh ) P=${1:=/tmp/} RDN=zsh_git_repos/ Rs=(github/ gitlab/ sourceforge/) URLs=( https://github.com/zsh-users/zsh.git https://gitlab.com/zsh-org/zsh.git git://git.code.sf.net/p/zsh/code ) [[ ! -d $P$RDN ]] && mkdir $P$RDN for N ({1..${#Rs}}) { print '\n'${Rs[N]%/} [[ ! -d $P$RDN$Rs[N] ]] && mkdir $P$RDN$Rs[N] cd $P$RDN$Rs[N] print URL: $URLs[N]'\n'LogFileName: $P$RDN${Rs[N]}clone_error_log git clone $URLs[N] $D[N] 2>$P$RDN${Rs[N]}clone_error_log E=$? ; cd $OLDPWD ; print "return code: $E" [[ $E -eq 0 ]] && { print ; cd $P$RDN$Rs[N]zsh && git describe ; cd $OLDPWD } } # vim : ts=2 sw=2 sts=2 sta ai et ft=zsh : }
On Fri, Dec 16, 2022 at 1:05 PM Jim <linux.tech.guy@gmail.com> wrote: > > github > zsh-5.9-91-g1de8baded > > gitlab > zsh-5.9-85-g67d4bf5bb > > sourceforge > zsh-5.9-91-g1de8baded I think this is because Oliver and/or Daniel is/are manually updating gitlab, so its always going to be one attention-span behind. On Thu, Dec 15, 2022 at 1:26 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Actually, I do wonder why we don't use GitLab's built-in mirroring > thing. Perhaps in order to allow people to submit completion patches to > either GitHub or GitLab at their choice? How would where the patches are submitted affect this? We're always going to apply them back on the sourceforge origin. Conflicting patches for the same completion?
Bart Schaefer wrote on Sat, 17 Dec 2022 19:57 +00:00: > On Fri, Dec 16, 2022 at 1:05 PM Jim <linux.tech.guy@gmail.com> wrote: >> >> github >> zsh-5.9-91-g1de8baded >> >> gitlab >> zsh-5.9-85-g67d4bf5bb >> >> sourceforge >> zsh-5.9-91-g1de8baded > > I think this is because Oliver and/or Daniel is/are manually updating > gitlab, so its always going to be one attention-span behind. > Not me. Oliver? > On Thu, Dec 15, 2022 at 1:26 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: >> >> Actually, I do wonder why we don't use GitLab's built-in mirroring >> thing. Perhaps in order to allow people to submit completion patches to >> either GitHub or GitLab at their choice? > > How would where the patches are submitted affect this? We're always > going to apply them back on the sourceforge origin. Conflicting > patches for the same completion? I'm not worried about conflicting patches; that possibility comes with the territory. Rather, I was wondering whether "make <this> GL repository a mirror of <this> GH repository" might delete GL heads corresponding to merge requests (MRs), since they don't exist on the GH end being pulled from. (Cf. rsync's --delete option) Now, I'm not even sure whether the lag observed this week was a one-time thing or not. However, should we determine that the GitLab mirror's settings need to be changed, Oliver and I can effect such changes. Cheers, Daniel
[-- Attachment #1: Type: text/plain, Size: 683 bytes --] I have noticed this lag multiple times, so it's not a one off. On Sat, Dec 17, 2022 at 2:14 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Now, I'm not even sure whether the lag observed this week was a one-time > thing or not. However, should we determine that the GitLab mirror's > settings need to be changed, Oliver and I can effect such changes. > > Daniel > I have noticed this lag multiple times before, so it's not a one off. Generally GL catches up with the others within 24 to 48 hours AFAICT(don't have actual numbers). But since I manually update, and not every day, I really couldn't tell you how often this occurs or if there is some pattern. Regards, Jim [-- Attachment #2: Type: text/html, Size: 1138 bytes --]
Jim wrote on Sun, 18 Dec 2022 01:58 +00:00: > On Sat, Dec 17, 2022 at 2:14 PM Daniel Shahaf <d.s@daniel.shahaf.name> > wrote: > >> >> Now, I'm not even sure whether the lag observed this week was a one-time >> thing or not. However, should we determine that the GitLab mirror's >> settings need to be changed, Oliver and I can effect such changes. >> >> Daniel >> > > I have noticed this lag multiple times before, so it's not a one off. > Generally GL catches up with the others within 24 to 48 hours > AFAICT(don't have actual numbers). But since I manually update, and > not every day, I really couldn't tell you how often this occurs or if > there is some pattern. > More interestingly, the last commit on gitlab as of this writing is 67d4bf5bb936a5b95160410b4790f2bf4113c75f, even though another commit was pushed on the 14th at 05:06Z. (I'm basing this date on the sourceforge commit emails rather than on author dates or committer dates.) I'm not sure what does the pushes. It doesn't seem to be documented in the infra repository either. Oliver, any idea why gitlab hasn't updated in 4.5 days? Cheers, Daniel > Regards, > > Jim
"Daniel Shahaf" wrote: > I'm not sure what does the pushes. It doesn't seem to be documented in > the infra repository either. Oliver, any idea why gitlab hasn't updated in 4.5 days? It was configured so as to happen automatically. Looking now, under Settings→Repository→Mirroring repositories, everything appears blank and the only Mirror direction offered appears to be "Push". Documentation also appears to mention that pulling is an Ultimate only feature. It may have only stopped now because you logged in. There is a programme to allow open source projects to apply for that for free, see: https://about.gitlab.com/solutions/open-source/join/ However, I'm more inclined to delete the (now broken) mirror than jump through their hoops. I only ever fetched from it to get at the merge requests. A slight lag is not something I'd ever be especially concerned about. There have only been 16 merge requests. If we just want the extra backup, there are other options like codeberg and bitbucket. Oliver
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --] Hi, On Sun, Dec 18, 2022 at 5:40 PM Oliver Kiddle <opk@zsh.org> wrote: > "Daniel Shahaf" wrote: > > I'm not sure what does the pushes. It doesn't seem to be documented in > > the infra repository either. Oliver, any idea why gitlab hasn't updated > in 4.5 days? > > It was configured so as to happen automatically. Looking now, under > Settings→Repository→Mirroring repositories, everything appears blank and > the only Mirror direction offered appears to be "Push". Documentation > also appears to mention that pulling is an Ultimate only feature. It may > have only stopped now because you logged in. > > There is a programme to allow open source projects to apply for that for > free, see: https://about.gitlab.com/solutions/open-source/join/ > > However, I'm more inclined to delete the (now broken) mirror than jump > through their hoops. > > I only ever fetched from it to get at the merge requests. A slight lag > is not something I'd ever be especially concerned about. There have only > been 16 merge requests. If we just want the extra backup, there are > other options like codeberg and bitbucket. > > Oliver > Just wondering if there has been any decision made about the gitlab repository. AFAICT it hasn't updated for allmost three months. gitlab: zsh-5.9-85-g67d4bf5bb github and sourceforge: zsh-5.9-160-g9bd9693fd Again, just curious. Regards, Jim [-- Attachment #2: Type: text/html, Size: 2061 bytes --]