Well
==> for R1/beta6 the Haiku revision version is hrev59886+79 - it equals ‘current’ on that branch of development, until devs do not select some additional merged patches to add beta6 branch too.
That ‘current’ is at the end of the repo URL, and if you thoroughly analyse the URL and think what an URL means the same time ..
.. this is also a directory /and a path to it) as well, on a repository server (in case the Haiku repo)
Which means, if the buildmaster (the compiling service that build new level of Haiku compiles using newly merged sources into binaries and config files and supporting program libraries and after creating installable packages from these 3 kind of SW stuff, so make from merged pactches a new Haiku in the scheduled time night in CET or CEST timezone - or for manual launch of an admin on that server , like Alexander {kallisti5} or Augistine {waddlesplash} - then the new packages will be added to a directory on that server that exactly have the same revision number that the highest merged patch revision number found on that night at the beginning of the scheduled event, or anytime when manually launched…
So when buildmaster finishes the new Haiku level those packages will be in the new directory with new revision number (the weird repo URL, as nephele wrote), and it’s enough to create a new ‘current’ “directory” as a link that point to that directory – containing the actual highest available binary packages of Haiku. At least this is the most reasonable thing that the building and providing automatically should work this way. If I made mistake in my theory - I’m sure admins can correct me.
So, when you setup the URL of Haiku repository to set to a direct hrevxxxxx revision level directory on the repository server, instead of ‘current’ “directory” that changes at every new Haiku level built, then you have a Haiku repo setting, that point to a specific Haiku revision.
So you can upgrade to that version only, and no matter how many new Haiku version built.
Otherwise, it can be useful, if you have a scheduled Haiku upgrade running on your Haiku, and you want to stay on a specific level, then you can stay on that level, and you dont have to stop your scheduled pkgman update command, just set the repo URL to a specific version, and Haiku will stay on that level - just don’t forget restore the right repo URL, when you would like to restore the normal upgrading :)) where upgrade can happen again 
(those + 79 are selected patches above hrev59886 - those judged by devs safe to implement in beta version besides targeted issues or safe improvements during transition/testing period of new Beta)
As there is another branch too … for example if I talked about x86_64 above
==> for R1/Development or actually that’s R1/beta7 the Haiku revision version is hrev60037 - this is the actual ‘current’ for Haiku Nightly
This revision as built and also ready to download from Haiku site as install image, It actually matches merged patches level, but sometimes you can already install a newer level, while to download a new install image with new revision from Haiku site … it takes some time.
And also sometimes shit happens, and some buildmuster process fails in the night - it was such before in this year where Haiku32 bit built for new revision, but for 64 bit the builmaster had problem, so it turned out when more people anticipated a new patch and must be waited for next night to be compiled and packaged for us, end users ;-))
With parallel , Haiku creates so called unsupported install images for RISC-V, and ARM and ARM64 as well - those have bleeding edge nightly revisions, and not supported as you may have reach desktop, b ut you should have developer or masochist as no repos, so you should develop/compile anything that bare Haiku in the installer. If you even can boot into desktop and not struggling to patch boot process to get reach Desktop, and after you finally reached the services and OS stuff just crashes, so the things you would use or rely on to fix things.
So, for your question
really about understand these hrev number belongs 2 different Haiku branch, so your understanding would correct, if you at the same time would switch from Beta(6 actually) repo to the Haiku Nightly, as well.
As from hrev59886+79 of the Beta, you won’t upgrade to hrev60030 - just partially as + 79 means 79 patches so selected new versions that merged above hrev59886, so we can say Beta6 freezed on that level basically, and between 59886 to 60030 or 60037, now have 144 or 151 new patch from that 79 selected to add , possibly selectively copied on server to the beta6 branch’s appropriate source storage directories. This way this requires manual work to add new stuff on decision making beyond patch merging.
So I can say, you understood well that some had set the direct revision directory - which is in case points to a Haiku nightly version - wont get the newer version built above that Haiku version.
However right after that you mentined the R1/beta6 current version, that is a quite different Haiku with quite different upgrade plan and SW in it - Beta6 just partly in a selected way contains Haiku Nightly fixes and improvements.
You can switch between them, but you must understand that if you switch to Nightly, then you must switch Haikuports to Nightly Haikuports repo, as supporting program libraries are on different levels, and some applications you cannot install if you are not on Nightly and if you switch back Beta6 the packages will be uninstalled and reinstalled from Haikuports Beta repo.
I hope I could give it to you what should understand when you just checked the revision numbers and you just partially right about and thought it’s the same when compared the numbers only.
Unfortunately you misunderstod the version numbers among two different Haiku release - Beta and Nightly and ther version numbers.
It is right they refers to the same patches,patchlevels, but they were not cross numbers if you are on Beta version - never reach the affected number of Nightly. If it ment for you as releave as no problem actual is still under that number or you mentioned from other reasons.
To cross that number on Beta6 can be possible - it comes from behaviour of selected patches, you just explicitly check out on CGIT view to of the 2 branches, as the last viewable patchlevel will be hrev59886 - all other patches above sits there without hrev numbers. So you must go to ‘master’ branch that covers the Nightly version of Haiku and find the same patch by title to have the revision number.
So, I can say in case Haiku Beta what’s in the ‘current’ is not so obvious as in case Haiku Nightly, where you can just recreate the ‘current’ should point to the new directory with packages built under that hrev number.
I do not attempt to describe, how it can be constructed, so not exactly simple to point to a new directory as in case master branch. Possibly after hrev59886, a new directory created as when a selection happens or addition to it, and may the directory name as simple as in the version that is : ‘hrev59886+79’ so now current is created such or similar directory, but it is more some guessing from my side. So you have a possibility to set repo in case Beta too to a direct composed level, but not so obvious as in case ‘master’ branch and Haiku Nighly. More safe to use only ‘current’ in case Beta repo.
I hope I could explain well the difference and grocked to not mixed the two release of Haiku and their far related but yet different revision numbers.
