Why are there no version numbers like there was in CVS? For example, text.dat.
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
Where are you looking? There are labels (e.g. sbbs317b) and there are commit IDs. This is what git provides.
digital man
Synchronet/BBS Terminology Definition #25:
DTE = Data Terminal Equipment
Norco, CA WX: 91.7°F, 44.0% humidity, 16 mph ENE wind, 0.00 inches rain/24hrs
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
Where are you looking? There are labels (e.g. sbbs317b) and there are commit IDs. This is what git provides.
digital man
Synchronet/BBS Terminology Definition #25:
DTE = Data Terminal Equipment
Norco, CA WX: 91.7°F, 44.0% humidity, 16 mph ENE wind, 0.00 inches rain/24hrs
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
Where are you looking? There are labels (e.g. sbbs317b) and there are commit IDs. This is what git provides.
digital man
Synchronet/BBS Terminology Definition #25:
DTE = Data Terminal Equipment
Norco, CA WX: 91.7°F, 44.0% humidity, 16 mph ENE wind, 0.00 inches rain/24hrs
Why are there no version numbers like there was in CVS? For example, text.dat.
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
This was already answered in DM's announcement post.
Git doesn't do that.
DaiTengu
... Old age is life's parody.
---
■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
This was already answered in DM's announcement post.
Git doesn't do that.
DaiTengu
... Old age is life's parody.
---
■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
Where are you looking? There are labels (e.g. sbbs317b) and there are commit IDs. This is what git provides.
No I mean the version number for example, the recent text.dat was 1.125.
Then how do you know if you have the latest version?
Re: GitHub
By: The Millionaire to DaiTengu on Mon Aug 24 2020 03:40 pm
You run "git status". If you don't have git, well, then you don't know. But that was true of the text.dat file before. The text.dat file did not have revision number embedded in it.
digital man
Synchronet/BBS Terminology Definition #82:
UART = Universal Asynchronous Receiver/Transmitter
Norco, CA WX: 89.9°F, 47.0% humidity, 12 mph NNE wind, 0.00 inches rain/24hrs
Re: GitHub
By: The Millionaire to DaiTengu on Mon Aug 24 2020 03:40 pm
You run "git status". If you don't have git, well, then you don't know. But that was true of the text.dat file before. The text.dat file did not have revision number embedded in it.
Could you please embed the version number into text.dat please? Thanks.
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 05:46 pm
I think what you're asking for is the CVS revision number. We're not using CVS any longer and that number was never embedded in the text.dat file.
digital man
This Is Spinal Tap quote #33:
Nigel Tufnel: Well, so what? What's wrong with bein' sexy?
Norco, CA WX: 87.6°F, 51.0% humidity, 13 mph E wind, 0.00 inches rain/24hrs
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 05:46 pm
I think what you're asking for is the CVS revision number. We're not using CVS any longer and that number was never embedded in the text.dat file.
What about the tarball you had before. What happens to that now? sbbs.tar or something to that effect.
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 05:56 pm
Still built nightly. http://wiki.synchro.net/dev:source
digital man
Synchronet "Real Fact" #106:
You're missing the action in #synchronet at irc.synchro.net!
Norco, CA WX: 86.8°F, 52.0% humidity, 10 mph NNE wind, 0.00 inches rain/24hrs
Then how do you know if you have the latest version?
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm
This was already answered in DM's announcement post.
Git doesn't do that.
DaiTengu
... Old age is life's parody.
---
■ Synchronet ■ War Ensemble BBS - The sport is war, total war -
warensemble.com
Then how do you know if you have the latest version?
This was already answered in DM's announcement post.
Git doesn't do that.
Why doesn't it?
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 05:56 pm
Still built nightly. http://wiki.synchro.net/dev:source
No, I'm talking about the tarball you had on cvs before.
No I mean the version number for example, the recent text.dat was 1.125.
Then how do you know if you have the latest version?
Why are there no version numbers like there was in CVS? For example, text.dat.
Why doesn’t it?
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 06:02 pm
So, that is an option in viewcvs/cvsweb, and GitLab has something comparable (even better as you have the option of .zip). Use the "Download" button on the page: https://gitlab.synchro.net/sbbs/sbbs
digital man
Synchronet/BBS Terminology Definition #17:
DCD = Data Carrier Detect
Norco, CA WX: 81.9°F, 61.0% humidity, 16 mph E wind, 0.00 inches rain/24hrs
It was the GNU tarball.
Then how do you know if you have the latest version?
just git pull and git status you dont need more
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 18:12:00
Go away.
GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY GO AWAY
Please.
---
echicken
electronic chicken bbs - bbs.electronicchicken.com
■ Synchronet ■ electronic chicken bbs - bbs.electronicchicken.com
Then how do you know if you have the latest version?
You run "git status". If you don't have git, well, then you don't know. But that was true of the text.dat file before. The text.dat file did not have revision number embedded in it.
Re: GitHub
By: Digital Man to The Millionaire on Mon Aug 24 2020 04:20 pm
Then how do you know if you have the latest version?
You run "git status". If you don't have git, well, then you don't know. But that was true of the text.dat file before. The text.dat file did not have revision number embedded in it.
Do you know if there's a way to have Git insert the commit IDs in the files similar to how CVS was inserting the CVS version numbers, using a tag of some kind?
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 18:12:00
Go away.
Please.
Why don't you go away? We don't need people like you around anyways.
Re: GitHub
By: Nightfox to Digital Man on Mon Aug 24 2020 07:24 pm
I haven't played it yet, but apparently there is a way to have some git commands insert blob hash (or commit-ID?) into the $Id:$ keyword embedded in files: https://stackoverflow.com/questions/1792838/how-do-i-enable-the-ident-string- for-a-git-repository
The problems with this are:
1. It's not the same format as the CVS Id keyword expansion (not even close) 2. The $Revision:$ keyword isn't expanded, which is what I usually use in source files to grab/report the CVS revision of the file.
But I intend to look more into it and other potential solutions to the incrementing file revision.
digital man
Synchronet "Real Fact" #91:
Captured chat with Wayne Bell: http://wiki.synchro.net/history:waynebell_chat Norco, CA WX: 79.8°F, 62.0% humidity, 5 mph ESE wind, 0.00 inches rain/24hrs
Re: GitHub
By: The Millionaire to echicken on Mon Aug 24 2020 07:54 pm
Not to pick sides or anything, but echicken runs one of the most custom, best looking and reliable BBSes today. And he's responsible for creating and supporting some of the coolest features/addons to Synchronet (including that web UI you like to use). So yeah, we like having people like echicken around.
digital man
Sling Blade quote #23:
Karl: I reckon I'm gonna have to get used to looking at pretty people.
Norco, CA WX: 79.0°F, 62.0% humidity, 9 mph NE wind, 0.00 inches rain/24hrs
Why don't you go away? We don't need people like you around anyways.
BBSes today. And he's responsible for creating and supporting some of the coolest features/addons to
Synchronet (including that web UI you like to use). So yeah, we like having people like echicken
Why don't you go away? We don't need people like you around anyways.
I think I'm getting pretty comfy with the github. Looks pretty straightforward once you start to use it.
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/
Well then him to clean up his behaviour.
echicken
electronic chicken bbs - bbs.electronicchicken.com
Synchronet electronic chicken bbs - bbs.electronicchicken.com
Why don't you go away? We don't need people like you around anyways.
$ The Millionaire $
Well then him to clean up his behaviour.
$ The Millionaire $
Re: GitHub
By: Digital Man to The Millionaire on Mon Aug 24 2020 20:03:14
In fairness, none of that buys me the right to be a jerk.
---
echicken
electronic chicken bbs - bbs.electronicchicken.com
■ Synchronet ■ electronic chicken bbs - bbs.electronicchicken.com
Why don't you go away? We don't need people like you around anyways.
Re: GitHub
By: Nightfox to Digital Man on Mon Aug 24 2020 07:24 pm
Re: GitHub
By: Digital Man to The Millionaire on Mon Aug 24 2020 04:20 pm
Then how do you know if you have the latest version?
You run "git status". If you don't have git, well, then you don't know.
But that was true of the text.dat file before. The text.dat file did not have revision number embedded in it.
Do you know if there's a way to have Git insert the commit IDs in the files
similar to how CVS was inserting the CVS version numbers, using a tag of some kind?
I haven't played it yet, but apparently there is a way to have some git commands insert blob hash (or commit-ID?) into the $Id:$ keyword embedded in files:
https://stackoverflow.com/questions/1792838/how-do-i-enable-the-ident-string-for-a-git-repository
The problems with this are:
1. It's not the same format as the CVS Id keyword expansion (not even close) 2. The $Revision:$ keyword isn't expanded, which is what I usually use in source files to grab/report the CVS revision of the file.
But I intend to look more into it and other potential solutions to the incrementing file revision.
digital man
Re: Re: GitHub
By: Ragnarok to The Millionaire on Mon Aug 24 2020 09:37 pm
Then how do you know if you have the latest version?
just git pull and git status you dont need more
Generally, versioning systems are developer tools and aren't really meant for software distribution systems. Regular users shouldn't have to install a versioning system to download something.
Nightfox
El 25/8/20 a las 00:00, Digital Man escribi:
Re: GitHub
By: Nightfox to Digital Man on Mon Aug 24 2020 07:24 pm
Re: GitHub
By: Digital Man to The Millionaire on Mon Aug 24 2020 04:20 pm
Then how do you know if you have the latest version?
You run "git status". If you don't have git, well, then you don't know.
But that was true of the text.dat file before. The text.dat file did not have revision number embedded in it.
Do you know if there's a way to have Git insert the commit IDs in the files
similar to how CVS was inserting the CVS version numbers, using a tag of some kind?
I haven't played it yet, but apparently there is a way to have some git commands insert blob hash (or commit-ID?) into the $Id:$ keyword embedded in files: https://stackoverflow.com/questions/1792838/how-do-i-enable-the- ident-string- for-a-git-repository
The problems with this are:
1. It's not the same format as the CVS Id keyword expansion (not even close) 2. The $Revision:$ keyword isn't expanded, which is what I usually use in source files to grab/report the CVS revision of the file.
But I intend to look more into it and other potential solutions to the incrementing file revision.
digital man
Maybe creating some kind of hook. A script that read the Id from the
file and increment it
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
But, i think that is not necesary had the old versioning method into the actual git..
On 08-24-20 19:28, Nightfox wrote to Ragnarok <=-
Re: Re: GitHub
By: Ragnarok to The Millionaire on Mon Aug 24 2020 09:37 pm
Then how do you know if you have the latest version?
just git pull and git status you dont need more
Generally, versioning systems are developer tools and aren't really
meant for software distribution systems. Regular users shouldn't have
to install a versioning system to download something.
On 08-24-20 23:37, echicken wrote to The Millionaire <=-
Re: GitHub
By: The Millionaire to Digital Man on Mon Aug 24 2020 20:06:36
I think I'm getting pretty comfy with the github. Looks pretty straightforward once you start to use it.
Might want to turn your attention to GitLab, then, which is what we're actually using.
On 08-24-20 19:28, Nightfox wrote to Ragnarok <=-
Re: Re: GitHub
By: Ragnarok to The Millionaire on Mon Aug 24 2020 09:37 pm
Then how do you know if you have the latest version?
just git pull and git status you dont need more
Generally, versioning systems are developer tools and aren't really meant for software distribution systems. Regular users shouldn't have to install a versioning system to download something.
True, and you don't with Git, you can download a .zip off the web interface at
Github. But that said, it's actually less fiddly to run a git clone if you have git installed. :)
But you still end up overwriting anything you changed whether you get the latest zip or whether you pull the latest direct from git.
True, and you don't with Git, you can download a .zip off the web interface at
Github. But that said, it's actually less fiddly to run a git clone if you have git installed. :)
But you still end up overwriting anything you changed whether you get the latest zip or whether you pull the latest direct from git.
I totally agree that versioning systems are not meant for software distribution. Many sysops can barely scape by with Linux and CVS without throwing in the added complication of git. I feel this is going to force those on the fence about giving up their BBS to go away, or may push others to not bother installing updates any more. I'm likely to be in that crowd. I don't have a lot of time to dedicate to my BBS right now as it is, without having to jump through hoops to update it.
While I can understand this is useful for DM and other developers, I can only see this hurting sbbs in the end because cvs just works, and now it doesn't
and sysops are going to be forced to make changes they don't want or don't need. I'm all for progress, but this seems like a regresion to me.
This, of course, is MHO and I'll probably just be accused of whining over nothing. We'll see...
Re: Re: GitHub
By: Nelgin to Tony Langdon on Wed Aug 26 2020 11:45 am
But you still end up overwriting anything you changed whether you get the latest zip or whether you pull the latest direct from git.
Actually, for git - git pull doesnt overwrite local changes.
If git finds that a pull will change files that have been modified locally, it will refuse to checkout the pull. In which case, you may need to "git stash" your changes for the pull to complete, and then "git stash pop" to re-apply your changes and manually resolve any conflicts.
I actually do this a lot, since I develop on my laptop and fix on the server, and changes on my laptop are often not yet committed to git...
Re: Re: GitHub
By: alterego to Nelgin on Thu Aug 27 2020 05:13 am
Unfortunately, I think some people are confused because I've combined both source code and run-time (e.g. text/config files) into the same repo. When I first imported the CVS history into Git, I made multiple repositories (approximating the "modules" I had in the CVS repo) but then later had a change of mind and decided a Git "monorepo" was the better approach for this project.
I'm also of the opinion that nobody should ever try to "sync" their run-time files (e.g. the contents of the ctrl and text directories) with the source repository - unless they are very aware of what files to synchronize and what not to. This is as true for Git as it was true of CVS. With CVS, you could selectively update "modules" or "directories" and thus avoid (if you were careful) the synchronization of those run-time files with the source repo. With Git, the solution is to simply store the repo is a separate directory (e.g. sbbs/repo). You can still use tools like 'diff' to compare your changes (in the case of text files), but Git should now solve the problem of merge conflict markers appearing mysteriously in sysops' configuration or text files. It'll be harder for *nix to accidentally screw up their configurations. Most of this doesn't matter at all to Windows sysops.
digital man
This Is Spinal Tap quote #26:
David St. Hubbins: They were still booing him when we came on stage.
Norco, CA WX: 93.6°F, 37.0% humidity, 3 mph N wind, 0.00 inches rain/24hrs
CVS doesn't do some magic thing that you as a sysop needed. If you just want to update to the latest executables and scripts, download 2 files and extract into your exec dir:
http://vert.synchro.net/sbbs/sbbsexec.tgz
I'm also of the opinion that nobody should ever try to "sync" their run-time files (e.g. the contents of the ctrl and text directories) with the source repository - unless they are very aware of what files to synchronize and what not to. This is as true for Git as it was true of
So, some time ago I added login to chat_sec.js to load the @smeg mail reader if it exists. I kept this in /sbbs/exec because if there were any changes to chat_sec.js in the future (which there were) CVS would merge my modifications and it worked well. I had no problems. The below procedure would blow away that change. Of course, I could put it in mods but then no updates. So no-win situation.
I totally agree that versioning systems are not meant for software distribution. Many sysops can barely scape by with Linux and CVS without throwing in the added complication of git.
I feel this is going to force those
on the fence about giving up their BBS to go away, or may push others to not bother installing updates any more. I'm likely to be in that crowd. I don't have a lot of time to dedicate to my BBS right now as it is, without having to
jump through hoops to update it.
While I can understand this is useful for DM and other developers, I can only see this hurting sbbs in the end because cvs just works, and now it doesn't and sysops are going to be forced to make changes they don't want or don't need. I'm all for progress, but this seems like a regresion to me.
Re: Re: GitHub
By: alterego to Nelgin on Thu Aug 27 2020 05:13 am
Re: Re: GitHub
By: Nelgin to Tony Langdon on Wed Aug 26 2020 11:45 am
But you still end up overwriting anything you changed whether you get the latest zip or whether you pull the latest direct from git.
Actually, for git - git pull doesnt overwrite local changes.
If git finds that a pull will change files that have been modified locally,
it will refuse to checkout the pull. In which case, you may need to "git stash" your changes for the pull to complete, and then "git stash pop" to re-apply your changes and manually resolve any conflicts.
I actually do this a lot, since I develop on my laptop and fix on the server, and changes on my laptop are often not yet committed to git...
Unfortunately, I think some people are confused because I've combined both source code and run-time (e.g. text/config files) into the same repo. When I first imported the CVS history into Git, I made multiple repositories (approximating the "modules" I had in the CVS repo) but then later had a change of mind and decided a Git "monorepo" was the better approach for this project.
I'm also of the opinion that nobody should ever try to "sync" their run-time files (e.g. the contents of the ctrl and text directories) with the source repository - unless they are very aware of what files to synchronize and what not to. This is as true for Git as it was true of CVS. With CVS, you could selectively update "modules" or "directories" and thus avoid (if you were careful) the synchronization of those run-time files with the source repo. With Git, the solution is to simply store the repo is a separate directory (e.g. sbbs/repo). You can still use tools like 'diff' to compare your changes (in the case of text files), but Git should now solve the problem of merge conflict markers appearing mysteriously in sysops' configuration or text files. It'll be harder for *nix to accidentally screw up their configurations. Most of this doesn't matter at all to Windows sysops.
digital man
I notice that gitlab can execute server-side hooks too.Maybe creating some kind of hook. A script that read the Id from the
file and increment it
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
But, i think that is not necesary had the old versioning method into the actual git..
Yup. Most of those are client-side hooks (not copied into the repo itself, so not present in other clones) - so not useful. Some kind of server-side hook maybe. I plan to look into it more.
digital man
I totally agree that versioning systems are not meant for software distribution. Many sysops can barely scape by with Linux and CVS without throwing in the added complication of git. I feel this is going to force throwing in the added complication of git. I feel this is going to force those on the fence about giving up their BBS to go away, or may push others to not bother installing updates any more. I'm likely to be in that crowd. I don't have a lot of time to dedicate to my BBS right now as it is, without having to jump through hoops to update it.
Actually, for git - git pull doesnt overwrite local changes.
If git finds that a pull will change files that have been modified locally, it will refuse to checkout the pull. In which case, you may need to "git stash" your changes for the pull to complete, and then "git stash pop" to re-apply your changes and manually resolve any conflicts.
It will if you do things the "easy" way.
git reset --hard
Re: Re: GitHub
By: Digital Man to Nelgin on Wed Aug 26 2020 12:38:29
So, some time ago I added login to chat_sec.js to load the @smeg mail reader if it exists. I kept this in /sbbs/exec because if there were any changes to chat_sec.js in the future (which there were) CVS would merge my modifications and it worked well.
I had no problems. The below procedure
would blow away that change. Of course, I could put it in mods but then no updates. So no-win situation.
CVS doesn't do some magic thing that you as a sysop needed. If you just want to update to the latest executables and scripts, download 2 files and extract into your exec dir:
http://vert.synchro.net/sbbs/sbbsexec.tgz
Except it throws a 404...but still, I wouldn't be using that method.
Re: Re: GitHub
By: Digital Man to alterego on Wed Aug 26 2020 12:53 pm
Hey,
I'm also of the opinion that nobody should ever try to "sync" their run-time files (e.g. the contents of the ctrl and text directories) with the source repository - unless they are very aware of what files to synchronize and what not to. This is as true for Git as it was true of
I havent thought this through, but would it work if ctrl and text where git submodules? (Given your "monorepo" configuration)
Your right, runtime should not be mixed with development and the way we normally consume applications they by definition are. The "make install" probably should build a target tree for "usage" (and the first time it builds a bigger tree, but there after just updates the appropraite branches) - but havent thought that through either...
Maybe creating some kind of hook. A script that read the Id from the file and increment it
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
But, i think that is not necesary had the old versioning method into the actual git..
Yup. Most of those are client-side hooks (not copied into the repo itself, so not present in other clones) - so not useful. Some kind of server-side hook maybe. I plan to look into it more.
I notice that gitlab can execute server-side hooks too.
https://docs.gitlab.com/ee/administration/server_hooks.html#create-a-server- hoo k-for-a-repository
Then, is the file version really necessary?
Tracker1 wrote to Nelgin <=-to
On 8/26/2020 9:45 AM, Nelgin wrote:
I totally agree that versioning systems are not meant for software distribution. Many sysops can barely scape by with Linux and CVS without throwing in the added complication of git.
Git is *NOT* any harder to use by someone not contributing than
CVS is... IMO it's actually easier to use than CVS/SVN, but
that's just my own take. Mostly because you don't have to deal
with being offline trying to reach a server to lock a file.
Branching is crazy easy compared to what CVS/SVN do.
I feel this is going to force those
on the fence about giving up their BBS to go away, or may push others to not bother installing updates any more. I'm likely to be in that crowd. I don't have a lot of time to dedicate to my BBS right now as it is, without having
jump through hoops to update it.only
That's where the .zip downloads come in handly... Beyond that, if
you're comfortable with your backups, then you should become more
familiar with how things work.
While I can understand this is useful for DM and other developers, I can
see this hurting sbbs in the end because cvs just works, and now it doesn't and sysops are going to be forced to make changes they don't want or don't need. I'm all for progress, but this seems like a regresion to me.
No, CVS does emphatically *NOT* "just work" ... There are reasons
why Subversion (SVN) largely replaced CVS and why distributed
source control is so much more popular today.
This is anything but a regression, it allows for more/broader
contribution and for a BBS Sysop is largely a difference of your
source co-mingled vs having it in a separate /sbbs/repo
directory.
alterego wrote to Nelgin <=-
So, some time ago I added login to chat_sec.js to load the @smeg mail reader if it exists. I kept this in /sbbs/exec because if there were any changes to chat_sec.js in the future (which there were) CVS would merge my modifications and it worked well. I had no problems. The below procedure would blow away that change. Of course, I could put it in mods but then no updates. So no-win situation.
Nah, git will merge them in too. At first it will complain that
you have a locally modified file - so you "git stash", then "git
pull" and finally "git stash pop". (And if git stash pop
complained of conflicts, you would manually address them, and not
forget to "git stash drop && git reset HEAD <name of conlicting
files>".)
Sure perhaps a different way of getting the job done, and perhaps
a few more steps as well - but in the scheme of the bigger
picture, git out does CVS with both arms behind your back...
What about those of us who don't know all that git foo?
What about those of us who don't know all that git foo?
On 08-26-20 11:45, Nelgin wrote to Tony Langdon <=-
But you still end up overwriting anything you changed whether you get
the latest zip or whether you pull the latest direct from git.
I totally agree that versioning systems are not meant for software distribution. Many sysops can barely scape by with Linux and CVS
without throwing in the added complication of git. I feel this is going
to force those on the fence about giving up their BBS to go away, or
may push others to not bother installing updates any more. I'm likely
to be in that crowd. I don't have a lot of time to dedicate to my BBS right now as it is, without having to jump through hoops to update it.
While I can understand this is useful for DM and other developers, I
can only see this hurting sbbs in the end because cvs just works, and
now it doesn't and sysops are going to be forced to make changes they don't want or don't need. I'm all for progress, but this seems like a regresion to me.
This, of course, is MHO and I'll probably just be accused of whining
over nothing. We'll see...
On 08-26-20 21:05, Gamgee wrote to Tracker1 <=-
Believe it or not, nearly ALL sysops know nothing about git, and
don't want to expend the effort to learn all the secret switches
and command line arguments. I know, it's probably time for the
comeback: "Well, learn git". Arggghhh.
On 08-26-20 12:38, Digital Man wrote to Nelgin <=-
Yeah, I'm not sure what're trying to convey. You liked CVS and we're no longer using it. You don't *have* to use Git to stay up-to-date. You didn't have to use CVS for that either.
echicken wrote to Gamgee <=-
What about those of us who don't know all that git foo?
I would say:
1) Wait a while, and expect some scripts, automation, and
evolving instructions to appear, which should make all of this
about as easy as it was with CVS
2) Don't use developer tools if you don't have to. If you don't
want to learn how to use Git, you can always automate downloading
and extracting the build/run archives.
2a) CVS was abused as a distribution/software-update platform
here for a long, long time, but it was never really the right
thing to do. We all got used to it, we all have some unlearning
to do.
3) Use your mods directory for any modified scripts. Don't keep
modified scripts in exec or any of its subdirectories. This is
one area where, if you do use Git to get updates, you can save
yourself a lot of trouble.
4) Ask for help or advice when it comes to any particular part of
the update process that concerns or causes problems for you. This
is a big change, so who knows what problems and solutions will
emerge.
5) Don't jump into it. This goes back to item 1. Things will need
some ironing out for a while, and if that's not a ride you want
to go on, you don't have to (until you really want/need an
update).
Tony Langdon wrote to Gamgee <=-
Believe it or not, nearly ALL sysops know nothing about git, and
don't want to expend the effort to learn all the secret switches
and command line arguments. I know, it's probably time for the
comeback: "Well, learn git". Arggghhh.
As a non developer, I find both git and cvs to have a similar
learning curve, except that the git options seem to be in plainer language.
Digital Man wrote to Gamgee <=-
What about those of us who don't know all that git foo?
Download .tgz files for the updates you desire. Or learn a few
basic git command ("git clone", "git pull") - they're even listed
on the Synchronet wiki now.
Yes, I'd agree and find them both a little confusing. The part
about git that worries/confuses me is that it seems harder to
update and not lose your configuration/customization. I could be
wrong about that, and am watching carefully as things unfold.
Gonna hold off on updating for a bit... ;-)
https://docs.gitlab.com/ee/administration/server_hooks.html#create-a-server-
hoo k-for-a-repository
Yup, I've been looking at them and experimenting.
Then, is the file version really necessary?
It certainly comes in handy when I can tell a sysop that the reported problem was fixed (or the requested feature added) in msglist.js revision 1.12. Oh, you have rev 1.14? Cool, you already have it. Oh, you have revision 1.11? You should update that file (at minimum).
digital man
Sure perhaps a different way of getting the job done, and perhaps
a few more steps as well - but in the scheme of the bigger
picture, git out does CVS with both arms behind your back...
Nightfox wrote to Gamgee <=-
Re: Re: GitHub
By: Gamgee to Tony Langdon on Thu Aug 27 2020 07:48 am
Yes, I'd agree and find them both a little confusing. The part
about git that worries/confuses me is that it seems harder to
update and not lose your configuration/customization. I could be
wrong about that, and am watching carefully as things unfold.
Gonna hold off on updating for a bit... ;-)
I think a couple general tips that can help are:
- Put customized JS scripts, Baja, etc. in sbbs/mods. Then you
can put all the standard stuff in the standard directories, and
you shouldn't have to worry so much about wiping out your stuff
in mods.
- Don't update sbbs/ctrl from the repository.
And for things like text.dat, be careful about merging in new
lines into yours.
- Don't update sbbs/ctrl from the repository.
Understood, but how do I tell it (git) not to do that? All I see
in the instructions (Wiki) is to do a "git pull".
Digital Man wrote to Gamgee <=-
What about those of us who don't know all that git foo?
Download .tgz files for the updates you desire. Or learn a few
basic git command ("git clone", "git pull") - they're even listed
on the Synchronet wiki now.
Yes, I will do one or the other. Probably not update for a while
until things settle out a bit. The basic commands are not an
issue, it's the "stash"/"pop"/"merge" stuff to protect existing configuration that worries/confuses me.
Part of this is just grumpiness and resistance to change, too.
:-)
Tony Langdon wrote to Gamgee <=-
Believe it or not, nearly ALL sysops know nothing about git, and
don't want to expend the effort to learn all the secret switches
and command line arguments. I know, it's probably time for the comeback: "Well, learn git". Arggghhh.
As a non developer, I find both git and cvs to have a similar
learning curve, except that the git options seem to be in plainer language.
Yes, I'd agree and find them both a little confusing. The part
about git that worries/confuses me is that it seems harder to
update and not lose your configuration/customization. I could be
wrong about that, and am watching carefully as things unfold.
El 26/8/20 a las 22:50, Digital Man escribi:
https://docs.gitlab.com/ee/administration/server_hooks.html#create-a-se rve r-
hoo k-for-a-repository
Yup, I've been looking at them and experimenting.
Then, is the file version really necessary?
It certainly comes in handy when I can tell a sysop that the reported problem was fixed (or the requested feature added) in msglist.js revision 1.12. Oh, you have rev 1.14? Cool, you already have it. Oh, you have revision 1.11? You should update that file (at minimum).
Another idea, instead of using the version number, which leads to keep
the increment, you could commit a timestamp that is better than the hash
to somehow identify "the version" of the file
Always, you can reply with "please, update the latest version at https://gitlab/lablab/lastest+all+fixed+now/msglist.js and try again"
CVS *DID* "just work", and made it easy for *nix sysops to stay
current. Notice I said "sysops", not "professional developers".
Believe it or not, nearly ALL sysops know nothing about git, and
don't want to expend the effort to learn all the secret switches
and command line arguments. I know, it's probably time for the
comeback: "Well, learn git". Arggghhh.
from the repository. And for things like text.dat, be careful about merging in new lines into yours.
Now you did it - you mentioned the file that DARE NOT BE NAMED!
On 08-27-20 07:48, Gamgee wrote to Tony Langdon <=-
As a non developer, I find both git and cvs to have a similar
learning curve, except that the git options seem to be in plainer language.
Yes, I'd agree and find them both a little confusing. The part
about git that worries/confuses me is that it seems harder to
update and not lose your configuration/customization. I could be
wrong about that, and am watching carefully as things unfold.
Gonna hold off on updating for a bit... ;-)
Nightfox wrote to Gamgee <=-
- Don't update sbbs/ctrl from the repository.
Understood, but how do I tell it (git) not to do that? All I see
in the instructions (Wiki) is to do a "git pull".
I'm not sure how you have your Synchronet BBS set up, but I think
it's probably best not to run Synchronet from a software
development repository. I don't think that's what version
control software like Git, SVN, etc. was designed for.. I think
it would probably be best to keep your Synchronet installation
directory separate from where you check out Synchronet code from
the repository. Then you wouldn't risk wiping out anything of
your own by doing an update from the repisotory. And also, it
then wouldn't really matter how you update Synchronet.. By
keeping things separate like that, you could update by either
updating the Git repository or downloading the daily runtime
archives, and then copy into your Synchronet installation
directory.
And I don't know if there's a way to tell Git not to update
certain directories.. That's one reason I don't think it's good
practice to be running your Synchronet from the software
repository directory - it's just not what version control
software was designed for.
And I totally agree with what echicken said earlier, that we've been misusing/abusing CVS as a software update delivery platform for a long
time and some of us (mostly the *nix sysops) have become accustomed to
that. We can probably do something similar with Git going forward, but
I'm not sure that that's the best option either.
Many sysops have become used to getting updates immediately after
they've been committed (which is a bit brave in some cases).
Previously, with CVS, it was *much* easier to accidentally lose configuration/customization via a repository update.
Rampage wrote to Gamgee <=-
Sure perhaps a different way of getting the job done, and perhaps
a few more steps as well - but in the scheme of the bigger
picture, git out does CVS with both arms behind your back...
Gamgee> Yeah, this all sounds great, assuming one is a
Gamgee> professional developer who uses git all day, every day.
Gamgee> What about those of us who don't know all that git foo?
we wait until the new workflow is worked out... one that is
known, i'm sure a few scripts that follow that workflow will
appear ;)
remember, as sysops, we specialize in automating everything via
scripts O:)
I agree on it not being a good idea to run from /sbbs/repo ...,
but now that I think about it, haven't most of us always been
doing that with CVS, sort of? We update the ../src structure from
CVS, then recompile, and (probably) have it symlink the
executables in ../exec back to the ../src tree. Right?
Agreed. If I end up using git in the future, perhaps have the
local repo in /home/user/whatever, pull updates and compile, and
then copy the appropriate new stuff to the actual /sbbs/
directories. Problem is, knowing what to copy... :(
Digital Man wrote to Gamgee <=-
What about those of us who don't know all that git foo?
Download .tgz files for the updates you desire. Or learn a few
basic git command ("git clone", "git pull") - they're even listed
on the Synchronet wiki now.
Yes, I will do one or the other. Probably not update for a while
until things settle out a bit. The basic commands are not an
issue, it's the "stash"/"pop"/"merge" stuff to protect existing configuration that worries/confuses me.
Right, and that's why I recommend cloning the sbbs git repo into
a different directory (e.g. sbbs/repo). Then you won't need to
stash / pop / merge stuff. I think it was someone else that said
that's how *they* did it, but that person is comfortable with git
already. You don't need to follow their work flow.
And I totally agree with what echicken said earlier, that we've
been misusing/abusing CVS as a software update delivery platform
for a long time and some of us (mostly the *nix sysops) have
become accustomed to that. We can probably do something similar
with Git going forward, but I'm not sure that that's the best
option either. Many sysops have become used to getting updates
immediately after they've been committed (which is a bit brave in
some cases).
Git was certainly the best option for concurrent distributed
development *and* we get all kinds of cool 3rd-party and open
source support stuff for it. It's a learning curve for me too
(e.g. setting up continuous integration builds on GitHub and
GitLab), but it's a good healthy one.
Digital Man wrote to Gamgee <=-
Yes, I'd agree and find them both a little confusing. The part
about git that worries/confuses me is that it seems harder to
update and not lose your configuration/customization. I could be
wrong about that, and am watching carefully as things unfold.
Yeah, it's actually the opposite: git will refuse to clone a
repository into non-empty working directory. Additionally, the
updated *nix installer will clone the repo into a sub-directory
(e.g. sbbs/repo) so there is zero chance of any subsequent
updates over-writing your local changes unless you're actually
modifying files in sbbs/repo/*, which of course, you're free to
do, but that's quite different than modifying files in
sbbs/ctrl/* or sbbs/text/*.
Previously, with CVS, it was *much* easier to accidentally lose configuration/customization via a repository update.
I suppose you could just make a copy of the whole repository tree, as Synchronet needs most of those files anyway. In the case of CVS, CVS keeps a subdirectory in each directory (called .cvs, I think) where it keeps CVS repository information. Just for running Synchronet, you don't need those .cvs subdirectories, but you could keep everything else. I think Git might keep track of repository information similarly, but I don't remember for sure.
I think a couple general tips that can help are:
- Put customized JS scripts, Baja, etc. in sbbs/mods. Then you can put all the standard stuff in the standard directories, and you shouldn't have to worry so much about wiping out your stuff in mods.
- Don't update sbbs/ctrl from the repository. And for things like text.dat, be careful about merging in new lines into yours.
TTBOMU: one thing to be aware of is that git doesn't like binary files changing a lot... IIRC, git is mainly diffs and diffs on binaries is not done... the entire binary is stored... so you have the original binary in the
repo as well as the complete binary of each update rather than the diffs between each update of the binary... this is one of the fundamental differences between git and other source code management packages...
Many sysops have become used to getting updates immediately after
they've been committed (which is a bit brave in some cases).
once the workflow is figured out and understood, this can still be done quite easily...
I disagree completely, on all of it.
CVS *DID* "just work", and made it easy for *nix sysops to stay
current. Notice I said "sysops", not "professional developers".
Believe it or not, nearly ALL sysops know nothing about git, and
don't want to expend the effort to learn all the secret switches
and command line arguments. I know, it's probably time for the
comeback: "Well, learn git". Arggghhh.
Yes, I will do one or the other. Probably not update for a while
until things settle out a bit. The basic commands are not an
issue, it's the "stash"/"pop"/"merge" stuff to protect existing
configuration that worries/confuses me.
Part of this is just grumpiness and resistance to change, too.
:-)
Thanks for the reply, and for what you do.
Well...
Un> It will if you do things the "easy" way.
Un> git reset --hard
Does throw away your local changes.
But... "git pull" doesnt - so yes, if you git pull after "git reset", then it will pull updates - but the "git reset" threw away your local changes...
"git stash" is a useful thing to remember...
Yeah, this all sounds great, assuming one is a professional
developer who uses git all day, every day.
What about those of us who don't know all that git foo?
But you still end up overwriting anything you changed whether you
get the latest zip or whether you pull the latest direct from git.
Actually, for git - git pull doesnt overwrite local changes.
If git finds that a pull will change files that have been modified locally, it will refuse to checkout the pull. In which case, you may need to "git stash" your changes for the pull to complete, and then "git stash pop" to re-apply your changes and manually resolve any conflicts.
I actually do this a lot, since I develop on my laptop and fix on the server, and changes on my laptop are often not yet committed to git...
Previously, with CVS, it was *much* easier to accidentally lose configuration/customization via a repository update.
Nightfox wrote to Gamgee <=-
- Don't update sbbs/ctrl from the repository.
Understood, but how do I tell it (git) not to do that? All I see
in the instructions (Wiki) is to do a "git pull".
I'm not sure how you have your Synchronet BBS set up, but I think
it's probably best not to run Synchronet from a software
development repository. I don't think that's what version
control software like Git, SVN, etc. was designed for.. I think
it would probably be best to keep your Synchronet installation directory separate from where you check out Synchronet code from
the repository. Then you wouldn't risk wiping out anything of
your own by doing an update from the repisotory. And also, it
then wouldn't really matter how you update Synchronet.. By
keeping things separate like that, you could update by either
updating the Git repository or downloading the daily runtime
archives, and then copy into your Synchronet installation
directory.
I have it running (on Linux) from /sbbs, as a non-root user.
I agree on it not being a good idea to run from /sbbs/repo ...,
but now that I think about it, haven't most of us always been
doing that with CVS, sort of?
We update the ../src structure from
CVS, then recompile, and (probably) have it symlink the
executables in ../exec back to the ../src tree. Right?
And I don't know if there's a way to tell Git not to update
certain directories.. That's one reason I don't think it's good practice to be running your Synchronet from the software
repository directory - it's just not what version control
software was designed for.
Agreed. If I end up using git in the future, perhaps have the
local repo in /home/user/whatever, pull updates and compile, and
then copy the appropriate new stuff to the actual /sbbs/
directories. Problem is, knowing what to copy... :(
Re: Re: GitHub
By: Digital Man to Gamgee on Thu Aug 27 2020 14:00:22
And I totally agree with what echicken said earlier, that we've been misusing/abusing CVS as a software update delivery platform for a long time and some of us (mostly the *nix sysops) have become accustomed to that. We can probably do something similar with Git going forward, but I'm not sure that that's the best option either.
TTBOMU: one thing to be aware of is that git doesn't like binary files changing a lot...
Digital Man wrote to Gamgee <=-
What about those of us who don't know all that git foo?
Download .tgz files for the updates you desire. Or learn a few
basic git command ("git clone", "git pull") - they're even listed
on the Synchronet wiki now.
Yes, I will do one or the other. Probably not update for a while
until things settle out a bit. The basic commands are not an
issue, it's the "stash"/"pop"/"merge" stuff to protect existing configuration that worries/confuses me.
Right, and that's why I recommend cloning the sbbs git repo into
a different directory (e.g. sbbs/repo). Then you won't need to
stash / pop / merge stuff. I think it was someone else that said
that's how *they* did it, but that person is comfortable with git already. You don't need to follow their work flow.
Oh! So, am I understanding this correctly: If I clone the git
repo into /sbbs/repo, and then as updates happen, I do a "git
pull", and recompile... If I use SYMLINKS=1 on my command line,
the new executables will be linked from /sbbs/exec to
/sbbs/repo/exec. So far, so good.
Then I can do the copying of
the updated 'exec' and 'text' directories (via tarball downloads),
just as I always have.
Then restore customized stuff to
/sbbs/text and /sbbs/text/menu (that I backed up prior to
updating). I also have some custom stuff in /sbbs/mods, and
understand about that. Then run "../exec/jsexec update" and
restart.
If the above is correct, then nothing will have changed in my
workflow as compared to how I have done it with CVS. Only
difference is the addition/use of the /sbbs/repo directory. One
of the keys is that I don't edit/change anything in the ../repo
directory. Is this all right?
Git was certainly the best option for concurrent distributed development *and* we get all kinds of cool 3rd-party and open
source support stuff for it. It's a learning curve for me too
(e.g. setting up continuous integration builds on GitHub and
GitLab), but it's a good healthy one.
Yes, I get that too. Although I'm grumbling a little, I do
appreciate that you're advancing the product (SBBS) and I'm sure I
speak for all sysops when I say Thank You for that.
Digital Man wrote to Gamgee <=-
Yes, I'd agree and find them both a little confusing. The part
about git that worries/confuses me is that it seems harder to
update and not lose your configuration/customization. I could be
wrong about that, and am watching carefully as things unfold.
Yeah, it's actually the opposite: git will refuse to clone a
repository into non-empty working directory. Additionally, the
updated *nix installer will clone the repo into a sub-directory
(e.g. sbbs/repo) so there is zero chance of any subsequent
updates over-writing your local changes unless you're actually modifying files in sbbs/repo/*, which of course, you're free to
do, but that's quite different than modifying files in
sbbs/ctrl/* or sbbs/text/*.
I think I'm finally starting to understand this a little. My
previous post of a few minutes ago had some questions that I hope
you can answer to assure me that I do understand it... :)
To summarize here, for most of us, we should not modify anything
in /sbbs/repo , correct?
Just do the updates (git pull) into
there, recompile, and restore custom stuff to /sbbs/text...
It's harder to explain, but imo easier to actually work with in
practice... but it is a bit different to work with, as you no longer
deal with file locking, but potential merge/rebase conflicts.
Re: Re: GitHub
By: alterego to Nelgin on Thu Aug 27 2020 05:13 am
But you still end up overwriting anything you changed whether you
get the latest zip or whether you pull the latest direct from git.
Actually, for git - git pull doesnt overwrite local changes.
If git finds that a pull will change files that have been modified locally, it will refuse to checkout the pull. In which case, you may need to "git stash" your changes for the pull to complete, and then "git stash pop" to re-apply your changes and manually resolve any conflicts.
I actually do this a lot, since I develop on my laptop and fix on the server, and changes on my laptop are often not yet committed to git...
So I'm thinking that maybe a local branch, like "bbsname" would be a good go-between.
For instance, I'd do something like:
git clone https://gitlab.synchro.net/sbbs/sbbs.git
git branch ensemble
<copy my edited files over>
<update .gitignore to ignore directories that contain files, message areas, mail, etc. things I don't need in git>
git add .
git commit
Then, when you want to update, you can do:
git status <see if there are any changes since last commit, if so, commit, ignore, or stash accordingly>
git pull origin master
<this will merge the master synchronet branch into your local branch, you'll likely have to enter a commit message, like "merged master">
rebuild or whatever, and verify everything is working. if not, you can revert your commit, do a clean rebuild, and you're back to an unbroken state.
It's cool that someone with Git-foo can do that, but I wouldn't be steering any other sbbs sysops to use that work-flow. :-)
Myself, I'm just symlinking files and dirs to the repo files or dirs as I go and find the need. For example, exec/load is a symlink to my repo's exec/load, but I have a *ton* of unadded/committed files in exec, so I'm just symlinking files to the repo's exec/* as needed in there. I think it's a balance based on how comfortable you are with revision control systems and the number of local edits you'll be making.
I think a couple general tips that can help are:
- Put customized JS scripts, Baja, etc. in sbbs/mods. Then you can
put all the standard stuff in the standard directories, and you
shouldn't have to worry so much about wiping out your stuff in mods. -
Don't update sbbs/ctrl from the repository. And for things like
text.dat, be careful about merging in new lines into yours.
I *never* edit text.dat, I just use the JS api to make the changes in
the modules that need them (login, logon, shell)... I don't have to
worry about overriding that way.
I suppose you could just make a copy of the whole repository tree, as
Synchronet needs most of those files anyway. In the case of CVS, CVS
keeps a subdirectory in each directory (called .cvs, I think) where it
keeps CVS repository information. Just for running Synchronet, you
don't need those .cvs subdirectories, but you could keep everything
else. I think Git might keep track of repository information
similarly, but I don't remember for sure.
Git is a bit different, it keeps the history for your tracked local branches in a .git directory... your working directory is "live" with where you are at, whatever active changes. CVS/SVN/TFVC required actual separate directory structures for branches, where git will just update your working directory to the branche/hash you are targetting.
Although CVS supported file locking (reserved check-outs or "edits" they called-them), I never used them.
At some point you "learned cvs" right? It's not inherently more difficult...
Re: Re: GitHub
By: Tracker1 to Nightfox on Fri Aug 28 2020 11:20 am
I think a couple general tips that can help are:
- Put customized JS scripts, Baja, etc. in sbbs/mods. Then you can
put all the standard stuff in the standard directories, and you
shouldn't have to worry so much about wiping out your stuff in mods. -
Don't update sbbs/ctrl from the repository. And for things like
text.dat, be careful about merging in new lines into yours.
I *never* edit text.dat, I just use the JS api to make the changes in the modules that need them (login, logon, shell)... I don't have to worry about overriding that way.
I guess that's true. I might look into using JS for that. But does that mean the JS runs every time someone logs in? Or whenever Synchronet starts?
I think I'm finally starting to understand this a little. My
previous post of a few minutes ago had some questions that I hope
you can answer to assure me that I do understand it... :)
To summarize here, for most of us, we should not modify anything
in /sbbs/repo , correct? Just do the updates (git pull) into
there, recompile, and restore custom stuff to /sbbs/text...
On 8/27/2020 8:01 AM, Nightfox wrote:
I think a couple general tips that can help are:
- Put customized JS scripts, Baja, etc. in sbbs/mods. Then you can
put all the standard stuff in the standard directories, and you
shouldn't have to worry so much about wiping out your stuff in mods.
- Don't update sbbs/ctrl from the repository. And for things like
text.dat, be careful about merging in new lines into yours.
I *never* edit text.dat, I just use the JS api to make the changes in
the modules that need them (login, logon, shell)... I don't have to
worry about overriding that way.
I guess that's true. I might look into using JS for that. But does that mean the JS runs every time someone logs in? Or whenever Synchronet starts?
Nightfox
Tracker1 wrote to Gamgee <=-
CVS *DID* "just work", and made it easy for *nix sysops to stay
current. Notice I said "sysops", not "professional developers".
Believe it or not, nearly ALL sysops know nothing about git, and
don't want to expend the effort to learn all the secret switches
and command line arguments. I know, it's probably time for the
comeback: "Well, learn git". Arggghhh.
At some point you "learned cvs" right? It's not inherently more difficult...
clone (checkout) to /sbbs/repo, in the repo directory 'git pull'
to update and don't fucking touch the files in /sbbs/repo, copy
them out to where you use them. It's not any more difficult.
Digital Man wrote to Gamgee <=-
Yes, I will do one or the other. Probably not update for a while
until things settle out a bit. The basic commands are not an
issue, it's the "stash"/"pop"/"merge" stuff to protect existing configuration that worries/confuses me.
Right, and that's why I recommend cloning the sbbs git repo into
a different directory (e.g. sbbs/repo). Then you won't need to
stash / pop / merge stuff. I think it was someone else that said
that's how *they* did it, but that person is comfortable with git already. You don't need to follow their work flow.
Oh! So, am I understanding this correctly: If I clone the git
repo into /sbbs/repo, and then as updates happen, I do a "git
pull", and recompile... If I use SYMLINKS=1 on my command line,
the new executables will be linked from /sbbs/exec to
/sbbs/repo/exec. So far, so good.
Yup.
Then I can do the copying of
the updated 'exec' and 'text' directories (via tarball downloads),
just as I always have.
That's a little weird as you just pulled copies into repo/exec
and repo/text. Really doesn't make a lot of sense to then
download a tarball containing the exact same files.
Then restore customized stuff to
/sbbs/text and /sbbs/text/menu (that I backed up prior to
updating). I also have some custom stuff in /sbbs/mods, and
understand about that. Then run "../exec/jsexec update" and
restart.
Sounds good.
If the above is correct, then nothing will have changed in my
workflow as compared to how I have done it with CVS. Only
difference is the addition/use of the /sbbs/repo directory. One
of the keys is that I don't edit/change anything in the ../repo
directory. Is this all right?
Yup.
Git was certainly the best option for concurrent distributed development *and* we get all kinds of cool 3rd-party and open
source support stuff for it. It's a learning curve for me too
(e.g. setting up continuous integration builds on GitHub and
GitLab), but it's a good healthy one.
Yes, I get that too. Although I'm grumbling a little, I do
appreciate that you're advancing the product (SBBS) and I'm sure I
speak for all sysops when I say Thank You for that.
You're welcome and thanks for sticking around.
Tracker1 wrote to Gamgee <=-
Sorry if my last message was agressive. The point is... once you
have the git source cloned (checked out) at /sbbs/repo, just
don't edit anything in that directory, and you won't have issues.
`git pull` in that directory will get the latest.. from there,
you can do a build (don't recall the exact commands offhand) and
should be able to copy the updated /sbbs/repo/exec/** to
/sbbs/exec/** along with the updated binaries.
If you don't edit what's in /sbbs/repo, you won't have to worry
about stash/pop/merge ... in fact there's less chance of you
doing it on accident because it's in a different directory to
begin with.
If you keep your modified files on /sbbs/mods, then there's no
risk that you overwrite your local changes.
MRO wrote to Tracker1 <=-
I *never* edit text.dat, I just use the JS api to make the changes in
the modules that need them (login, logon, shell)... I don't have to
worry about overriding that way.
that's a good practice but if you do some big modifications it's
better to edit text.dat
most people wont need to do that, though. my text.dat is of epic proportions.
Tracker1 wrote to Gamgee <=-
Yeah, this all sounds great, assuming one is a professional
developer who uses git all day, every day.
What about those of us who don't know all that git foo?
Then use the nightly zip files to update against? For sysop use,
git isn't inherently harder than CVS was. And it might be
better, since a rule of thumb is, don't modify what's in
/sbbs/repo ... and if you work in /sbbs/mods instead of in
/sbbs/exec you can avoid most potential issues altogether.
Digital Man wrote to Gamgee <=-
I agree on it not being a good idea to run from /sbbs/repo ...,
but now that I think about it, haven't most of us always been
doing that with CVS, sort of?
For *nix sysops, yes.
We update the ../src structure from
CVS, then recompile, and (probably) have it symlink the
executables in ../exec back to the ../src tree. Right?
That's not really what we're talking about. "run from the repo"
means using the ctrl, text, node, xtrn directories from the repo
on a "live" BBS.
And I don't know if there's a way to tell Git not to update
certain directories.. That's one reason I don't think it's good practice to be running your Synchronet from the software
repository directory - it's just not what version control
software was designed for.
Agreed. If I end up using git in the future, perhaps have the
local repo in /home/user/whatever, pull updates and compile, and
then copy the appropriate new stuff to the actual /sbbs/
directories. Problem is, knowing what to copy... :(
Running "make install" in src/sbbs3 will automatically copy the
executable binaries to wherever your SBBSCTRL or SBBSEXEC
environment variables say they should go. "make symlinks" will
symlink the binaries instead.
Digital Man wrote to Gamgee <=-
Yes, I will do one or the other. Probably not update for a while until things settle out a bit. The basic commands are not an
issue, it's the "stash"/"pop"/"merge" stuff to protect existing configuration that worries/confuses me.
Right, and that's why I recommend cloning the sbbs git repo into
a different directory (e.g. sbbs/repo). Then you won't need to
stash / pop / merge stuff. I think it was someone else that said that's how *they* did it, but that person is comfortable with git already. You don't need to follow their work flow.
Oh! So, am I understanding this correctly: If I clone the git
repo into /sbbs/repo, and then as updates happen, I do a "git
pull", and recompile... If I use SYMLINKS=1 on my command line,
the new executables will be linked from /sbbs/exec to
/sbbs/repo/exec. So far, so good.
Yup.
Then I can do the copying of
the updated 'exec' and 'text' directories (via tarball downloads),
just as I always have.
That's a little weird as you just pulled copies into repo/exec
and repo/text. Really doesn't make a lot of sense to then
download a tarball containing the exact same files.
Well, in the past using CVS, following the Development Update
instructions on the Wiki... Under "Step 4 Runtime Files", then
specifically sub-steps 2,3,4... it tells me to get the daily
archive of exec and text, and extract them into the ../exec and
../text directories. Was that not necessary?
On 08-28-20 08:02, Gamgee wrote to Nightfox <=-
I agree on it not being a good idea to run from /sbbs/repo ...,
but now that I think about it, haven't most of us always been
doing that with CVS, sort of? We update the ../src structure from
CVS, then recompile, and (probably) have it symlink the
executables in ../exec back to the ../src tree. Right?
Agreed. If I end up using git in the future, perhaps have the
local repo in /home/user/whatever, pull updates and compile, and
then copy the appropriate new stuff to the actual /sbbs/
directories. Problem is, knowing what to copy... :(
For now, just gonna sit back and watch. :)
Digital Man wrote to Gamgee <=-
Oh! So, am I understanding this correctly: If I clone the git
repo into /sbbs/repo, and then as updates happen, I do a "git
pull", and recompile... If I use SYMLINKS=1 on my command line,
the new executables will be linked from /sbbs/exec to
/sbbs/repo/exec. So far, so good.
Yup.
Then I can do the copying of
the updated 'exec' and 'text' directories (via tarball downloads),
just as I always have.
That's a little weird as you just pulled copies into repo/exec
and repo/text. Really doesn't make a lot of sense to then
download a tarball containing the exact same files.
Well, in the past using CVS, following the Development Update
instructions on the Wiki... Under "Step 4 Runtime Files", then
specifically sub-steps 2,3,4... it tells me to get the daily
archive of exec and text, and extract them into the ../exec and
../text directories. Was that not necessary?
It was necessary. With CVS, you could update a subset of
"modules" (top-level directories), so we expressly *only* updated
the src and 3rdp modules (excluding the other "run-time"
directories to prevent over-writing or merging with the files of
a "live" BBS). With Git, you can't do that (you have to
fetch/pull the entire repo) - so we're putting the repo in a
sub-directory ("repo") and so you already have the files that
would be contained in the archives of the exec and text
directories.
Tony Langdon wrote to Gamgee <=-
I agree on it not being a good idea to run from /sbbs/repo ...,
but now that I think about it, haven't most of us always been
doing that with CVS, sort of? We update the ../src structure from
CVS, then recompile, and (probably) have it symlink the
executables in ../exec back to the ../src tree. Right?
Most would, because they use the symlinks as per the docs, but I personally am not doing mthat.
Agreed. If I end up using git in the future, perhaps have the
local repo in /home/user/whatever, pull updates and compile, and
then copy the appropriate new stuff to the actual /sbbs/
directories. Problem is, knowing what to copy... :(
"make install" (assuming there's a suitable install option in the Makefile).
For now, just gonna sit back and watch. :)
Probably wise for now, while things are settling and we're all
finding our feet.
On 08-30-20 07:59, Gamgee wrote to Tony Langdon <=-
Yep, understood. I will probably stop using the symlinks too,
once I get up the nerve to update from git.
"make install" (assuming there's a suitable install option in the Makefile).
Yes, that's the answer. Disk space is not an issue these days.
For now, just gonna sit back and watch. :)
Probably wise for now, while things are settling and we're all
finding our feet.
Yup! Thanks for the reply.
I *never* edit text.dat, I just use the JS api to make the changes in
the modules that need them (login, logon, shell)... I don't have to
worry about overriding that way.
I guess that's true. I might look into using JS for that. But does that mean the JS runs every time someone logs in? Or whenever Synchronet starts?
I *never* edit text.dat, I just use the JS api to make the changes in
the modules that need them (login, logon, shell)... I don't have to
worry about overriding that way.
that's a good practice but if you do some big modifications it's better to edit text.dat
most people wont need to do that, though. my text.dat is of epic proportions.
Although CVS supported file locking (reserved check-outs or "edits" they
called-them), I never used them.
In one of my early software engineering classes in college, the instructor set us up to use RCS, which seemed to come before CVS and SVN. With RCS, files were always locked when they were checked out, so if a file is in a 'checked out' state, ony the person who checked out the file can do any commits, until the file is committed & checked in again.
Sometimes we had issues if someone forgot to check some files back in when they were done doing making some changes.
At some point you "learned cvs" right? It's not inherently more
difficult...
I've used CVS and SVN in the past, and I've found Git to be more complex and thus more confusing at times than CVS and SVN. I started using Git at a past job a few years ago, and I feel okay with it now, but there are some things that I'm still confused about with Git. At my current place, we've been using Git, as well as Microsoft Azure to host our Git repositories. Azure and Visual Studio have some handy built-in tools that make some of the Git flows (such as branching, reviewing, and merging) fairly easy and straightforward.
One issue I've run into with Git is that when I'm working in a new branch, if I do a commit and then push my branch up, I've had some difficulties doing an amended commit after I've pushed my branch up. One thing I've heard is that it's good to do a 'git pull' to pull in anyone's changes, and if I do that after I've made some changes, it wants to do a merge with my branch. When that happens, I'm not sure where the merge is coming from. And then it often reports merge conflicts, even if nobody else has made changes - it seems to want to merge an older repo with mine, or something.. That's where I get confused.
CVS and SVN seem simpler - probably because they lack the branching & merging capabilities that Git has. With CVS and SVN, you can work from one branch, and doing a commit also means checking it in and pushing it up to the server.
Re: Re: GitHub
By: Tracker1 to Nightfox on Fri Aug 28 2020 11:36 am
It's harder to explain, but imo easier to actually work with in
practice... but it is a bit different to work with, as you no longer
deal with file locking, but potential merge/rebase conflicts.
Although CVS supported file locking (reserved check-outs or "edits" they called-them), I never used them.
Git is a bit different, it keeps the history for your tracked local
branches in a .git directory... your working directory is "live" with
where you are at, whatever active changes. CVS/SVN/TFVC required actual
separate directory structures for branches, where git will just update
your working directory to the branche/hash you are targetting.
In a broad sense though, I think it's the same basic idea. CVS stored repository info in .cvs directories, and Git stores repository/branch info in a .git directory. I was trying to explain that you could check out the Synchronet repository, build it, and then delete the repository metadata directory/directories and you'd have a Synchronet directory tree without all the repo data that you could run from.
On 8/29/2020 11:22 AM, MRO wrote:
Why would I need to edit my text.dat, I can replace any lines I want via JS... like on my login, I replace the sysop password prompt to fit into
my ansi, then change it back.
I generally set what I want/need close to where it is... mostly in login/logon/shell.
--
Michael J. Ryan
tracker1 +o Roughneck BBS
---
■ Synchronet ■ Roughneck BBS - coming back 2/2/20
Tracker1 wrote to MRO <=-proportions.
most people wont need to do that, though. my text.dat is of epic
Why would I need to edit my text.dat, I can replace any lines I
want via JS...
like on my login, I replace the sysop password
prompt to fit into my ansi, then change it back.
I generally set what I want/need close to where it is... mostly
in login/logon/shell.
138 posts so far. Incredible.
Why would I need to edit my text.dat, I can replace any lines I want via JS... like on my login, I replace the sysop password prompt to fit into my ansi, then change it back.
Tracker1 wrote to MRO <=-
most people wont need to do that, though. my text.dat is of epic
proportions.
Why would I need to edit my text.dat, I can replace any lines I
want via JS...
Well, one answer to that question would be... Many (most?)
sysops, including me, don't know how to do that. Believe it or
not, not everybody is a professional JS programmer, or even an
amateur JS programmer.
like on my login, I replace the sysop password
prompt to fit into my ansi, then change it back.
How do you do that? What filename are you editing to do that?
Also, why change it back?
I generally set what I want/need close to where it is... mostly
in login/logon/shell.
Okay... that probably answers my question above about what file(s)
to edit. But it still assumes that one knows how to edit JS. For
those that don't know JS, it's probably easier to edit text.dat.
Re: Re: GitHub
By: Tracker1 to MRO on Mon Aug 31 2020 05:10 pm
Why would I need to edit my text.dat, I can replace any lines I want via
JS... like on my login, I replace the sysop password prompt to fit into
my ansi, then change it back.
It seems to me there are benefits & tradeoffs either way. I've been in the habit of editing my text.dat, as some mods I downloaded long ago had that in their instructions. If you update your JS to modify your text.dat, the code would run every time someone logs in, which would take a little bit of time on every login. But at least you wouldn't have to worry about problems with your text.dat. Often I like to merge in new lines to my text.dat when the stock text.dat is updated though. Sometimes the existing lines in the stock text.dat are changed too.
Tracker1 wrote to Gamgee <=-
Why would I need to edit my text.dat, I can replace any lines I
want via JS...
Well, one answer to that question would be... Many (most?)
sysops, including me, don't know how to do that. Believe it or
not, not everybody is a professional JS programmer, or even an
amateur JS programmer.
// where 1 is the entry number in text.dat
bbs.replace_text(1, "new text");
like on my login, I replace the sysop password
prompt to fit into my ansi, then change it back.
How do you do that? What filename are you editing to do that?
Also, why change it back?
My /sbbs/mods/login.js in the case above. I set it back, because
there are other areas that ask for a sysop password. I add ansi
animation codes to position the cursor in the login ansi, and
then put it back after, so other areas of the BBS are unaffected.
I generally set what I want/need close to where it is... mostly
in login/logon/shell.
Okay... that probably answers my question above about what file(s)
to edit. But it still assumes that one knows how to edit JS. For
those that don't know JS, it's probably easier to edit text.dat.
It does take the knowledge of how to add it, it's not really
hard, and imo easier than text.dat ... also, it allows me to
update text.dat so that additions/changes (that I didn't make)
can come in without being messed up or missing in behavior.
146 posts. Unbelievable.
146 posts. Unbelievable.
146 posts. Unbelievable.
138 posts so far. Incredible.
Re: GitHub
By: The Millionaire to Digital Man on Thu Sep 03 2020 06:28 am
You're an idiot. Seriously..
There's a thread in another echo titled "Neuralink" that's up to almost 900 messages. no one cares. This happens all the time, you didn't start something, you're not keeping the conversation going.
Please kindly fuck the fuck off if you can't contribute anything meaningful.
DaiTengu
... A good man dies when a boy goes wrong.
---
■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
You're an idiot. Seriously..
There's a thread in another echo titled "Neuralink" that's up to
almost 900 messages. no one cares. This happens all the time, you
didn't start something, you're not keeping the conversation going.
Please kindly fuck the fuck off if you can't contribute anything
meaningful.
Oh I will once you leave Dove-Net permanently. You don't contribute to much except ***** and being an ******* at the same time. So you should talk *****.
Re: The Millionaire is a nuisance
By: The Millionaire to DaiTengu on Thu Sep 03 2020 07:59 pm
I have no idea what you're trying to say here. I read your message, thought "maybe I need a couple cups of coffee to help me understand what words go in place of "*****", but alas, a whole pot later and I still can't puzzle it out.
Multiple people here have tried to be nice. Hell, *I* have tried to be nice. We've all tried to get you to improve your posting, to contribute, rather than ask innane questions, and you just refuse.
Your posting is lazy. put some effort into it. This isn't Twitter, you don't have to keep your messages under 140 characters.
DaiTengu
... Renegade Tagline!! We're tired of Being Kidnapped!!! REBEL!!!!!
---
■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
| Sysop: | Chris Crash |
|---|---|
| Location: | Huntington Beach, CA. |
| Users: | 578 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 29:45:48 |
| Calls: | 10,736 |
| Calls today: | 1 |
| Files: | 5 |
| Messages: | 443,197 |
| Posted today: | 1 |