GitLab version history?

The older CVS repository had an overview of all recent changes – https://www.riscosopen.org/viewer/revisions

This was useful for looking at an overview of what has changed “recently”.

Is there an equivalent for GitLab? Because it seems to me that one needs to go to a source area (like “kernel”) and then select a tag (implying that one knows the tag to select) before anything like the same degree of detail is available – https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/commits/Kernel-6_19

This… What?! https://gitlab.riscosopen.org/groups/RiscOS/-/activity

This… What?! https://gitlab.riscosopen.org/groups/RiscOS/-/activity

Confusing, non-informative. I think it may have a use, and if the people that understand it get on with some coding we can just pick up the results.

Otherwise I feel sure that if you’d titled the thread “Irritating Git” it would have been a bit more representative.

This… What?! https://gitlab.riscosopen.org/groups/RiscOS/-/activity

For a complete overview, that’s probably the best place to look. The reason that the current view isn’t very useful is because the only significant thing that’s happened recently is the bulk import of the CVS repository – so the most recent history is the hundreds (if not thousands) of version tags being imported. Maybe if you keep scrolling long enough you’ll see some push events from where the actual code was imported.

Is there an equivalent for GitLab? Because it seems to me that one needs to go to a source area (like “kernel”) and then select a tag (implying that one knows the tag to select) before anything like the same degree of detail is available – https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/commits/Kernel-6_19

In CVS, the “MAIN”/“trunk” branch is the “correct” branch to look at for most components. In git, the “master” is the equivalent to MAIN: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/commits/master

So apart from the rare components where development occurs on a different branch (or situations where parallel development occurs on multiple branches), there’s no guesswork needed if you want to see the history for a single component. Although one downside of the gitlab web UI is that it doesn’t seem to annotate the commit history view with any coincidental branches/tags – so you can’t immediately see that (e.g.) commit 831e1d94 corresponds to Kernel-6_18.

Seeing the history for the entire source tree is a bit harder, since ROOL are making heavy use of submodules – so the activity view for the group is probably your best bet there.

Although one downside of the gitlab web UI is that it doesn’t seem to annotate the commit history view with any coincidental branches/tags – so you can’t immediately see that (e.g.) commit 831e1d94 corresponds to Kernel-6_18.

If you click on ‘Graph’ under ‘Repository’ on the menu in the left-hand column you will get a view that shows you all the tags and branches which should give you what you want.

Thanks – despite using it at work for the past couple of years, for some reason I never noticed that option!

However it’s still a bit lacking – there’s not enough space in the left hand column to see long branch/tag names (or multiple entries), and it would be nice to be able to go to places by clicking on the branch/tag names or the commit messages, instead of on the tiny graph node blobs. And there’s no year displayed!

The older CVS repository had an overview of all recent changes
This was useful for looking at an overview of what has changed “recently”.

My suggestion to ROOL of screen scraping the recent history turned out to be rather flakey in practice, or needing lots of heuristics that’ll no doubt break if the page layout is changed, so there’s some cunning rails thing that queries gitlab via an API. The most recent 10 or so are cached, top & tailed, to give most-recent-4 summaries on the front page.

I mentioned the missing most-recent-100 details to ROOL’s (web)master of the universe on 17th May, and he said “There is no equivalent of that for GitLab yet” so that implies at some point, as time allows, the ‘no/yet’ will become ‘an/now’.

Am I correct in my understanding that the last source code change was April 22, as from ‘recent changes in CVS’ – I look there frequently to make sure I keep up with any changes to RISC OS.

Am I correct in my understanding that the last source code change was April 22, as from ‘recent changes in CVS’ – I look there frequently to make sure I keep up with any changes to RISC OS.

No, latest change was 23rd May (at time of writing). The ‘recent changes in CVS’ list is frozen in time, but there’s not yet a ‘recent changes in Git’ customised equivalent, so in the meantime further up this thread are various suggestions of generic equivalents.

There’s quite a few wrinkles being ironed out, and nobody likes ironing!

No, latest change was 23rd May (at time of writing).

Which we mere mortals would expect to have produced a new build available on the downloads pages.
So, either there is no change in the source or the build environment is broken. Reasonable assumption?

Needs a big iron.

Also please note that I’m still working on the GitLab update integration. It’s not as simple as with the CVSHistory / XML parser stuff that existed at /viewer; we’re having to poll an API endpoint at the moment on a cron job. As we get more “realistic” commits into GitLab, we get a better idea of how the API data represents it and what we should be showing on e.g. the Home page’s “recent changes in GitLab” list – the API docs are poor, so it’s not clear without real life observation exactly how we should do it. Once that is nailed down, I can update the /viewer application appropriately.

Speaking of GitLab, there’s a file in the Wimp tests called [] which 404s when I click it.

Edit: In CVS the file is named [£] and hasn’t changed since 1997. This is presumably a case of £ not being a valid character in GitLab. The file itself doesn’t seem to have anything in it.

In CVS the file is named [£] and hasn’t changed since 1997

Looking in the old CSV derived Disc tarball I have the file shows as a zero byte item labelled [êëúèï] – as you say a 1997 artefact probably best cleaned out of its current home in Desktop.Wimp.TestO

Any odds on finding more crufty items elsewhere?

Or if you want a third opinion, the name should probably be [⇐⇒£⇓⇑] (which is what I’ve always seen it as under RISC OS when using Linux+Sunfish+CVS and native RISC OS Git). Chances are the gitlab web UI is expecting UTF-8 filenames, and so is falling over a bit when it sees filenames which use the Latin-1-ish RISC OS alphabet.

(The CVS viewer also fails to translate the arrow characters, but at least it’s sensible enough to correctly percent-encode the URL).

Any odds on finding more crufty items elsewhere?

This is the only oddly-named one that I’m aware of; I was extracting the tarball under Mac OS and it popped up and asked what that file’s name should be. No other files produced the prompt (although it may have remembered the selected encoding and used it automatically for any other files).

As we get more “realistic” commits into GitLab, we get a better idea of how the API data represents

At work we use TortoiseGit and it’s “Show Log” isn’t too bad. Looking at the sources way give you a hint of on how to use the API.

So, either there is no change in the source or the build environment is broken. Reasonable assumption?

Having seen the update of the Maestro code on Jun 1st, I expected to see a resultant new build in the downloads on Jun 2nd.

Looks to me like things aren’t building, or if they are then they aren’t being published to the downloads page(s)

Looks to me like things aren’t building, or if they are then they aren’t being published to the downloads page(s)

Probably not building, since it looks like they haven’t found a solution for managing the “Dev” products yet. (Just my theory – I haven’t talked to them about their git workflow yet)

This… What?! https://gitlab.riscosopen.org/groups/RiscOS/-/activity

For a complete overview, that’s probably the best place to look.

Correction: That’s actually a pretty poor place to look, since it doesn’t show the changes to any sub-groups (like the Maestro change Steve mentions). You can look at all the projects and sort them by last-updated, but that doesn’t immediately tell you what the changes were, so it seems like the best long-term solution will be to wait for Andrew to come up with an new “most recent 100 changes” page.

Probably not building, since it looks like they haven’t found a solution for managing the “Dev” products yet.

That was my assumed reason for it’s non-appearance.

I’m sure the nightly build from “Dev” is all in the plan they are working to…

I’m sure the nightly build from “Dev” is all in the plan they are working to…

Well, what was that line? Ah yes: “I love it when a plan comes together” – new builds for bonus binaries, HardDisc4 and System in the usual places.

The closest is at:

https://www.riscosopen.org/viewer/events

…and updates every 15 minutes or so. We have to pull that over API from the GitLab server, rather than being able to read info directly from a local CVS filesystem. We are still refining what kind of event data is shown there, since as you can see already from the activity page referenced above, the full event stream is rather confusing.

Only recent events will make much sense anyway, as older ones relate to initial CVS import and various experiments before the ROOL team had determined the best workflow and approach for source submissions.

I am currently writing a tool to add commits to the Product history for every submodule commit. This would allow one to explore the history and run tools such as git bisect.

For many post CVS commits neither the commit date nor the author date record when the commit was merged, as a result it is impossible to extract the history of a product from a clone of the ROOL git repositories, and is the cause of the confusing state of https://www.riscosopen.org/viewer/events

I suspect it will be possible to extract this from the Gitlab API, but that is not ideal. A fix would be too enable Semi-linear history merge requests.

You’ve also got to bear in mind that ROOL appear to be being naughty and are editing commits after they’ve been merged.

E.g. last night ROOL accepted this merge request. GitLab thinks it was merged with commit 806f1db7, but ROOL have edited the commit in order to apply the correct VersionNum changes, resulting in commit b3b95b4b.

Basically things would be a lot better if they stopped doing that and instead applied the VersionNum changes as part of the merge request, by pushing to the merger’s fork. Handily this would also result in a commit with the correct commit / author date, even if they squash the commits (I think).

The here is sample output from my commit adder. It won’t work if you just clone it from there as the relative submodule paths are wrong, but you can fetch it into a clone of ROOL’s Disc repository.

git fetch https://github.com/TimothyEBaldwin/RO_Disc all-commits:all-commits

The here is sample output from my commit adder.

Unfortunately that still doesn’t pick up the proper timeline for the appearance of these two:

Implement generic SDHCI version of GetTMCLK Author: Ben Avison
Date: Mon Jun 24 12:32:06 UTC 2019

Set BEN bit in SCTLR
Author: Ben Avison
Date: Sun Jun 23 21:32:16 UTC 2019

Which actually appeared for general public view on the Saturday some 24-ish hours after this:

Correct exit of CallbackCode to pull PC not LR
Author: John Ballance
Date: Fri Jun 28 10:27:33 UTC 2019

Obviously any system is dependent on the correct information being available to it.
“You’ve also got to bear in mind that ROOL appear to be being naughty” was the comment made above.

You’ve also got to bear in mind that ROOL appear to be being naughty and are editing commits after they’ve been merged.

It’s worse than that (though less nefarious, I think). It’s more a fundamental misunderstanding of how git should work. What they seem to have done is:

1. Accept the merge request into the central repo.
2. Simultanously, pull the requested commit from the forked repo into their own local copy and merge.
3. Add their version information and commit.
4. Squash the commits
5. Push the result

That’s a guess, of course – they might also have applied the requested merge as a patch to their local copy, added their own info and committed, but the fact that the commit message is identical suggests a squash.

At stage 5, git should have told them off for attempting to rewrite history, so either they ignored that and hit ‘force push’, or they had ‘force push’ defaulted on the IDE / client they were using. Either is a slapped wrist offence where I work (and in fact we’ve implemented server-side hooks precisely to stop that kind of behaviour).