• GitHub

    From The Millionaire@VERT to Digital Man on Mon Aug 24 17:22:06 2020
    Why are there no version numbers like there was in CVS? For example, text.dat.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to The Millionaire on Mon Aug 24 19:24:57 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm

    Why are there no version numbers like there was in CVS? For example, text.dat.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 19:30:30 2020
    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


    No I mean the version number for example, the recent text.dat was 1.125.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 19:33:10 2020
    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


    https://gitlab.synchro.net/sbbs/sbbs/-/blob/master/ctrl/text.dat

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 19:35:16 2020
    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


    https://gitlab.synchro.net/sbbs/sbbs/-/tree/master/ctrl

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From DaiTengu@VERT/ENSEMBLE to The Millionaire on Mon Aug 24 19:53:24 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 01:22 pm

    Why are there no version numbers like there was in CVS? For example, text.dat.

    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
  • From The Millionaire@VERT to DaiTengu on Mon Aug 24 19:37:44 2020
    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


    Why doesn’t it?

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to DaiTengu on Mon Aug 24 19:40:59 2020
    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?

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to The Millionaire on Mon Aug 24 20:18:17 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 03:30 pm


    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.

    That's a CVS *revision* number and no, Git doesn't provide those.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to The Millionaire on Mon Aug 24 20:20:27 2020
    Re: GitHub
    By: The Millionaire to DaiTengu on Mon Aug 24 2020 03:40 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.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 21:46:36 2020
    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


    Could you please embed the version number into text.dat please? Thanks.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to The Millionaire on Mon Aug 24 21:52:48 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 05:46 pm


    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.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 21:56:48 2020
    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

    What about the tarball you had before. What happens to that now? sbbs.tar or something to that effect.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to The Millionaire on Mon Aug 24 22:01:20 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 05:56 pm


    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.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 22:02:47 2020
    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


    No, I’m talking about the tarball you had on cvs before.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 22:06:38 2020
    It was sbbs.tar.gz

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 22:11:06 2020
    http://cvs.synchro.net/cgi-bin/viewcvs.cgi/

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 22:12:00 2020
    It was the GNU tarball.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From DaiTengu@VERT/ENSEMBLE to The Millionaire on Mon Aug 24 22:32:16 2020
    Re: GitHub
    By: The Millionaire to DaiTengu on Mon Aug 24 2020 03:40 pm

    Then how do you know if you have the latest version?

    probably the easiest way is

    git log -1 <filename>

    That will tell you what the latest commit is on the file.

    I mean, really, if you're not sure, you just do a git pull to make sure you're current, just like you would with cvs.

    DaiTengu

    ... Scepticism is the beginning of faith.

    ---
    ■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
  • From Ragnarok@VERT/DOCKSUD to The Millionaire on Tue Aug 25 01:37:47 2020
    El 24/8/20 a las 19:40, The Millionaire escribió:
    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?


    just git pull and git status you dont need more

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Nightfox@VERT/DIGDIST to The Millionaire on Mon Aug 24 23:23:14 2020
    Re: GitHub
    By: The Millionaire to DaiTengu on Mon Aug 24 2020 03:37 pm

    This was already answered in DM's announcement post.

    Git doesn't do that.

    Why doesn't it?

    As DM mentioned, Git provides commit IDs. That's just how it works. Different versioning systems will use different things for versioning.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man@VERT to The Millionaire on Mon Aug 24 23:29:56 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 06:02 pm


    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.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From echicken to The Millionaire on Tue Aug 25 02:49:23 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 18:12:00

    It was the GNU tarball.

    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
  • From Tracker1@VERT/TRN to The Millionaire on Mon Aug 24 21:07:33 2020
    On 8/24/2020 1:22 PM, The Millionaire wrote:
    Why are there no version numbers like there was in CVS? For example, text.dat.

    You can go into the file and click History at the top to see the history
    of that file.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to The Millionaire on Mon Aug 24 21:13:13 2020
    On 8/24/2020 3:30 PM, The Millionaire wrote:

    No I mean the version number for example, the recent text.dat was 1.125.

    https://gitlab.synchro.net/sbbs/sbbs/-/commits/master/ctrl/text.dat

    Git doesn't use incrementing revision numbers like CVS, it uses Commit hashes... usually you can use the first 8 characters which is unique
    enough for the git commands to identify a given hash.

    A tag is like a named pointer to a hash and is often used to identify controlled releases.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to The Millionaire on Mon Aug 24 21:15:26 2020
    On 8/24/2020 3:37 PM, The Millionaire wrote:

    Why doesn’t it?

    https://bit.ly/2EdWws1

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to The Millionaire on Mon Aug 24 21:17:42 2020
    On 8/24/2020 3:40 PM, The Millionaire wrote:

    Then how do you know if you have the latest version?

    In your /sbbs/repo (assuming you've checked out the latest)

    git pull

    will pull the latest from source control, then you can copy /sbbs/repo/ctrl/text.dat to /sbbs/ctrl/text.dat

    In a prior post, I linked to a full text.dat.js you could use to modify
    the lines you'd like to modify leaving the default in place for inclusion.

    NOTE: you only really need to modify the lines you'd want to modify, the
    file I linked to had all the defaults in place.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From The Millionaire@VERT to Digital Man on Mon Aug 24 23:44:56 2020
    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


    Nice. I love zip better. No need for iZip. :-)

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Nightfox@VERT/DIGDIST to Digital Man on Mon Aug 24 23:24:40 2020
    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?

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@VERT/DIGDIST to Ragnarok on Mon Aug 24 23:28:22 2020
    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

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From The Millionaire@VERT to echicken on Mon Aug 24 23:54:19 2020
    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


    Why don’t you go away? We don’t need people like you around anyways.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Nightfox on Tue Aug 25 00:00:15 2020
    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

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to The Millionaire on Tue Aug 25 00:03:14 2020
    Re: GitHub
    By: The Millionaire to echicken on Mon Aug 24 2020 07:54 pm


    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.

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Tue Aug 25 00:06:36 2020
    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


    I think I’m getting pretty comfy with the github. Looks pretty straightforward once you start to use it.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Tue Aug 25 00:07:48 2020
    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


    Well then him to clean up his behaviour.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From echicken to The Millionaire on Tue Aug 25 03:16:13 2020
    Re: GitHub
    By: The Millionaire to echicken on Mon Aug 24 2020 19:54:19

    Why don't you go away? We don't need people like you around anyways.

    Now now, I'm mostly joking around. I don't expect you to actually go away. Or change. Or learn. I can dream, though.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
  • From echicken to Digital Man on Tue Aug 25 03:36:10 2020
    Re: GitHub
    By: Digital Man to The Millionaire on Mon Aug 24 2020 20:03:14

    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

    In fairness, none of that buys me the right to be a jerk. I'd like to think I was just ... exuberantly expressing my frustration.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
  • From echicken to The Millionaire on Tue Aug 25 03:37:26 2020
    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.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
  • From echicken to The Millionaire on Tue Aug 25 03:44:16 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Mon Aug 24 2020 20:07:48

    Well then him to clean up his behaviour.

    :(

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
  • From Tracker1@VERT/TRN to The Millionaire on Tue Aug 25 00:37:23 2020
    On 8/24/2020 6:11 PM, The Millionaire wrote:
    http://cvs.synchro.net/cgi-bin/viewcvs.cgi/

    https://gitlab.synchro.net/sbbs/sbbs

    In the top-right corner, right next to clone is a download option.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From paulie420@VERT/BEERS20 to The Millionaire on Tue Aug 25 02:24:00 2020
    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 $

    Yes, we do... <smh> <lol>



    |07p|15AULIE|1142|07o
    |08.........
  • From paulie420@VERT/BEERS20 to The Millionaire on Tue Aug 25 02:29:00 2020
    Well then him to clean up his behaviour.

    $ The Millionaire $

    I hope that you are a millionaire, and have sent DigMan $thousand$; because that is the only reason I can think of that... I sometimes think you don't
    even get who does what and how green the topics you post and questions you
    ask show the community. I at least try to hide my ignorance a little... and I certainly know the people that write the code that we all use and love - I
    hope not for free in your case, as I stated earlier its the only reason I
    could think that folks didn't just twit you already; but maybe theres actual dumb there. Wow.

    Thanks echicken, dm, duece, nightfox, and a plethora of others - I'll
    continue to read between goof posts by 'the millionaires' to sponge up the
    data that I so love.

    shrug



    |07p|15AULIE|1142|07o
    |08.........
  • From The Millionaire@VERT to echicken on Tue Aug 25 09:13:01 2020
    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


    <sighs>

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Nightfox@VERT/DIGDIST to The Millionaire on Tue Aug 25 12:00:51 2020
    Re: GitHub
    By: The Millionaire to echicken on Mon Aug 24 2020 07:54 pm

    Why don't you go away? We don't need people like you around anyways.

    echicken has done a lot for the Synchronet community. You may have heard of his Synchronet web add-on, ecweb?

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Ragnarok@VERT/DOCKSUD to Digital Man on Tue Aug 25 17:26:24 2020
    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..

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Ragnarok@VERT/DOCKSUD to Nightfox on Tue Aug 25 17:28:41 2020
    El 24/8/20 a las 23:28, Nightfox escribió:
    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


    I Agree.. these user must download the release tarball and nothing more.

    Saludos!

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Digital Man@VERT to Ragnarok on Tue Aug 25 17:29:21 2020
    Re: Re: GitHub
    By: Ragnarok to Digital Man on Tue Aug 25 2020 01:26 pm

    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..

    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

    Synchronet "Real Fact" #43:
    Synchronet added Baja/PCMS support with v2.00a (1994).
    Norco, CA WX: 93.0°F, 40.0% humidity, 3 mph NE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Nightfox on Wed Aug 26 21:26:00 2020
    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. :)


    ... Deja Tue: A feeling that yesterday was Monday ...
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to echicken on Wed Aug 26 21:29:00 2020
    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.

    I'll have to work out the differences myself. I've been installing a lot of code from Github lately I can't recall anything I've installed from GitLab.


    ... Cursor: An expert in four-letter words
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Nelgin@VERT/EOTLBBS to Tony Langdon on Wed Aug 26 15:45:39 2020
    Tony wrote:
    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.

    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...

    ---
    ■ Synchronet ■ End Of The Line BBS - endofthelinebbs.com
  • From alterego@VERT/ALTERANT to Nelgin on Thu Aug 27 09:13:07 2020
    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...

    ...δεσ∩

    ... I'm not the one that misplaced the Deltivid asteroid belt!

    ---
    ■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to Nelgin on Wed Aug 26 16:38:29 2020
    Re: Re: GitHub
    By: Nelgin to Tony Langdon on Wed Aug 26 2020 11:45 am

    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.

    The sbbs_dev.zip (or .tgz for Linux-x64 sysops like yourself) contains *no* files that you might have changed. Download and update using that.

    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.

    Download a .tgz. Extract. No hoops.

    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

    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/sbbs_dev.tgz http://vert.synchro.net/sbbs/sbbsexec.tgz

    I think you're making this out to be more complicated than it is.

    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...

    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.

    digital man

    Sling Blade quote #3:
    Karl (re: killing Doyle): That second one just plum near cut his head in two. Norco, CA WX: 93.1°F, 34.0% humidity, 5 mph N wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to alterego on Wed Aug 26 16:53:06 2020
    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

    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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Wed Aug 26 17:12:45 2020
    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


    Looks like my thread is very popular I see. Never thought it would reach this far so far.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Nelgin@VERT/EOTLBBS to Digital Man on Wed Aug 26 19:18:48 2020
    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.

    ---
    ■ Synchronet ■ End Of The Line BBS - endofthelinebbs.com
  • From alterego@VERT/ALTERANT to Digital Man on Thu Aug 27 11:19:51 2020
    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...

    ...δεσ∩

    ... Free are those who dream dreams.

    ---
    ■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
  • From alterego@VERT/ALTERANT to Nelgin on Thu Aug 27 11:38:19 2020
    Re: Re: GitHub
    By: Nelgin to Digital Man on Wed Aug 26 2020 03:18 pm

    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...

    ...δεσ∩

    ... A mixture of admiration and pity is one of the surest recipes for affectio

    ---
    ■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
  • From Tracker1@VERT/TRN to Nelgin on Wed Aug 26 16:56:49 2020
    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 to
    jump through hoops to update it.

    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 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.

    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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Ragnarok@VERT/DOCKSUD to Digital Man on Thu Aug 27 00:09:57 2020

    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 notice that gitlab can execute server-side hooks too.

    https://docs.gitlab.com/ee/administration/server_hooks.html#create-a-server-hook-for-a-repository

    Then, is the file version really necessary?
    I think it's more a habit than a necessity

    Saludos!

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Ragnarok@VERT/DOCKSUD to Digital Man on Thu Aug 27 00:15:06 2020
    El 26/8/20 a las 16:53, Digital Man escribió:
    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 agree. I had a separate directory with the source. The only dir that i directly update from cvs was the "exec" and ocassionaly the xtrn , so is
    not necesary the have "one dir for all"

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Underminer@VERT/UNDRMINE to Nelgin on Wed Aug 26 22:24:22 2020
    Re: Re: GitHub
    By: Nelgin to Tony Langdon on Wed Aug 26 2020 11:45 am

    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.

    If you're concerned about accessibility, this is probably a really good move. It will likely cause some issues for some of the less tech saavy existing base when it comes to updating, but in terms of anyone new joining the fold it means sbbs now does things similarily to pretty much ALL other open source projects.

    Not to say that there shouldn't perhaps be some thought towards streamlining updates for the first group... but if you keep your mods in the mod folder, and setup a non-default shell for all your custom ansi, etc, there shouldn't be a whole lot overwritten in an update aside from a few settings.
    ---
    Underminer
    The Undermine BBS - bbs.undermine.ca:423
    Fidonet: 1:342/17
    ---
    ■ Synchronet ■ The Undermine - bbs.undermine.ca:423
  • From Underminer@VERT/UNDRMINE to alterego on Wed Aug 26 22:26:57 2020
    Re: Re: GitHub
    By: alterego to Nelgin on Thu Aug 27 2020 05:13 am

    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
    ---
    Underminer
    The Undermine BBS - bbs.undermine.ca:423
    Fidonet: 1:342/17
    ---
    ■ Synchronet ■ The Undermine - bbs.undermine.ca:423
  • From alterego@VERT/ALTERANT to Underminer on Thu Aug 27 14:48:37 2020
    Re: Re: GitHub
    By: Underminer to alterego on Wed Aug 26 2020 06:26 pm

    Well...

    It will if you do things the "easy" way.
    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...

    ...δεσ∩

    ... Health is merely the slowest possible rate at which one can die.

    ---
    ■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to Nelgin on Wed Aug 26 22:39:08 2020
    Re: Re: GitHub
    By: Nelgin to Digital Man on Wed Aug 26 2020 03:18 pm

    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.

    Until you git a merge conflict, but yes, that's exactly what CVS (and Git) are intended for. Now you can do the same with git, just copy the file to the repo's "exec" dir and then symlink it into your sbbs/exec dir.

    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.

    True, but there's no gaurantee that future updates to that file won't collide with your changes still. But if you're okay with that possibility, then you can create the same workflow the git by using a symlink. There are other potential solutions, but I think if you just have that one (or very few) locally modified files in your exec dir, then that's the best approach.

    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.

    Sorry, remove the "vert." from the hostname.

    digital man

    This Is Spinal Tap quote #1:
    Nigel Tufnel: These go to eleven.
    Norco, CA WX: 86.1°F, 48.0% humidity, 18 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to alterego on Wed Aug 26 22:42:06 2020
    Re: Re: GitHub
    By: alterego to Digital Man on Thu Aug 27 2020 07:19 am

    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)

    I've used submodules before and encountered their idiosyncracies. The main of including the run-time dirs (e.g. ctrl, text) in the repo was to support atomic commits to both source and run-times dirs.

    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...

    I was with you until "branches"... git branches? <shrug>

    digital man

    This Is Spinal Tap quote #21:
    So when you're playing you feel like a preserved moose on stage?
    Norco, CA WX: 86.1°F, 48.0% humidity, 18 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Ragnarok on Wed Aug 26 22:50:42 2020
    Re: Re: GitHub
    By: Ragnarok to Digital Man on Wed Aug 26 2020 08:09 pm


    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

    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

    Synchronet "Real Fact" #74:
    Vertrauen went online (as a WWIV BBS running on a 10MHz PC-XT clone) in 1988. Norco, CA WX: 85.1°F, 49.0% humidity, 11 mph NE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to alterego on Thu Aug 27 00:59:00 2020
    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...

    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?



    ... All hope abandon, ye who enter messages here.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Tracker1 on Thu Aug 27 01:05:00 2020
    Tracker1 wrote to Nelgin <=-

    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
    to

    jump through hoops to update it.

    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
    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.

    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.

    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.



    ... All hope abandon, ye who enter messages here.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Digital Man@VERT to Gamgee on Thu Aug 27 02:01:20 2020
    Re: Re: GitHub
    By: Gamgee to alterego on Wed Aug 26 2020 08:59 pm

    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.

    digital man

    This Is Spinal Tap quote #40:
    Morty the Mime: Come on, don't talk back, mime is money, come on, move it. Norco, CA WX: 75.6°F, 67.0% humidity, 2 mph E wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From echicken to Gamgee on Thu Aug 27 05:20:04 2020
    Re: Re: GitHub
    By: Gamgee to alterego on Wed Aug 26 2020 20:59:00

    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).

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
  • From Tony Langdon@VERT to Nelgin on Fri Aug 28 00:43:00 2020
    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.

    Will have to see how it's done.

    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.

    Guess I've spent too much time pulling source out of git and compiling lately. ;)

    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.

    Sounds like it certainly does make the development side easier. As for pulling stuff out of CVS, I think I only ever did that once or twice (other than a full installation or upgrade).

    This, of course, is MHO and I'll probably just be accused of whining
    over nothing. We'll see...

    Time will tell, let's see how it plays out. :)


    ... Excessive mouse activity detected. Running CAT.EXE to fix
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Digital Man on Fri Aug 28 00:46:00 2020
    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.

    I personally preferred the CVS way in the past, but I have a feeling I'll be just as happy with git. :)


    ... Let's split up, we can do more damage that way.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Gamgee on Fri Aug 28 00:56:00 2020
    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.


    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.


    ... Friends are the spice of life! Are you hot or mild?
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to Digital Man on Thu Aug 27 11:40:00 2020
    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.
    :-)

    Thanks for the reply, and for what you do.


    ... Enter any 12 digit prime number to continue.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to echicken on Thu Aug 27 11:44:00 2020
    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).

    Echicken, thanks for your reply and advice. Great stuff and
    greatly appreciated. I will be following *ALL* of that.
    Appreciate your patience and contributions very much.



    ... Looks like I picked a bad week to quit drinkin'.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Tony Langdon on Thu Aug 27 11:48:00 2020
    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.
    Gonna hold off on updating for a bit... ;-)


    ... Reality failure. Press Enter to continuum.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Nightfox@VERT/DIGDIST to Gamgee on Thu Aug 27 12:01:21 2020
    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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Ragnarok@VERT/DOCKSUD to Digital Man on Thu Aug 27 15:56:21 2020
    El 26/8/20 a las 22:50, Digital Man escribió:


    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

    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"

    =P

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Rampage@VERT/SESTAR to Gamgee on Thu Aug 27 16:31:27 2020
    Re: Re: GitHub
    By: Gamgee to alterego on Wed Aug 26 2020 20:59:00


    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 professional
    Gamgee> 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:)


    )\/(ark

    ---
    ■ Synchronet ■ The SouthEast Star Mail HUB - SESTAR
  • From Gamgee@VERT/PALANT to Nightfox on Thu Aug 27 15:57:00 2020
    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

    Yes, I already do that.

    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.

    Yep, got that.

    - 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".

    And for things like text.dat, be careful about merging in new
    lines into yours.

    Okay, not a factor for me, as I don't modify that.

    I'm gonna sit tight on updates for a while, and hope to see more clarification, instructions, scripts, etc to help out. Thanks.



    ... Internal Error: The system has been taken over by sheep at line 19960
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Nightfox@VERT/DIGDIST to Gamgee on Thu Aug 27 17:09:31 2020
    Re: Re: GitHub
    By: Gamgee to Nightfox on Thu Aug 27 2020 11:57 am

    - 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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man@VERT to Gamgee on Thu Aug 27 18:00:22 2020
    Re: Re: GitHub
    By: Gamgee to Digital Man on Thu Aug 27 2020 07:40 am

    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.

    Part of this is just grumpiness and resistance to change, too.
    :-)

    Definitely. :-)

    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

    Sling Blade quote #16:
    Karl Childers (to Doyle, re: lawn mower blade): I aim to kill you with it. Mmm. Norco, CA WX: 97.9°F, 25.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Gamgee on Thu Aug 27 18:05:12 2020
    Re: Re: GitHub
    By: Gamgee to Tony Langdon on Thu Aug 27 2020 07:48 am

    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.

    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.

    digital man

    This Is Spinal Tap quote #14:
    The Boston gig has been cancelled. [Don't] worry, it's not a big college town. Norco, CA WX: 98.3°F, 23.0% humidity, 11 mph ESE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Ragnarok on Thu Aug 27 18:06:24 2020
    Re: Re: GitHub
    By: Ragnarok to Digital Man on Thu Aug 27 2020 11:56 am

    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

    It's an idea.

    Always, you can reply with "please, update the latest version at https://gitlab/lablab/lastest+all+fixed+now/msglist.js and try again"

    No, I don't think that's a good idea.

    digital man

    Sling Blade quote #22:
    Karl: I don't reckon you have to go with women to be a good father to a boy. Norco, CA WX: 98.3°F, 23.0% humidity, 11 mph ESE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Lizard Master@VERT/NITEEYES to Gamgee on Thu Aug 27 20:18:13 2020
    Re: Re: GitHub
    By: Gamgee to Tracker1 on Wed Aug 26 2020 09:05 pm

    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.

    This sounds like a standard user response to any software upgrade since the beginning of time (I don't mean that to sound snarky) :).

    ---TLM

    ---
    ■ Synchronet ■ Nite Eyes BBS - To make people happy about my tagline everywhere...
  • From poindexter FORTRAN@VERT/REALITY to Nightfox on Thu Aug 27 20:46:58 2020
    Re: Re: GitHub
    By: Nightfox to Gamgee on Thu Aug 27 2020 08:01 am

    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!

    ---
    ■ Synchronet ■ realitycheckBBS -- http://realitycheckBBS.org
  • From Underminer@VERT/UNDRMINE to poindexter FORTRAN on Fri Aug 28 03:24:42 2020
    Re: Re: GitHub
    By: poindexter FORTRAN to Nightfox on Thu Aug 27 2020 04:46 pm

    Now you did it - you mentioned the file that DARE NOT BE NAMED!

    Yeah, now the Millionaire is going to set loose Mary Anne and the Professor upon us all.
    ---
    Underminer
    The Undermine BBS - bbs.undermine.ca:423
    Fidonet: 1:342/17
    ---
    ■ Synchronet ■ The Undermine - bbs.undermine.ca:423
  • From Tony Langdon@VERT to Gamgee on Sat Aug 29 00:48:00 2020
    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... ;-)

    I see there's two issues here. One is learning a new version control system, the other is the historical "bastardisation" of a version control system for storing and distributing live system files, a practice which now has the potential to bite us on the bom. :/ DM himself admitted to that.

    Most other software I install has a totally separate source tryy that can be anywhere on disk, with the runtime system being installed by "make install", and the installation process takes care to avoid clobbering runtime configuration files. On rare ocasions, I have even seen an extra "make" step to install default configuration files for a fresh installation.


    ... Why risk a hangover? Stay Drunk!!
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT to Nightfox on Fri Aug 28 12:02:00 2020
    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... :(

    For now, just gonna sit back and watch. :)



    ... 2 + 2 = 5 for extremely large values of 2.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.11-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rampage@VERT/SESTAR to Digital Man on Fri Aug 28 12:39:32 2020
    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... 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...

    one of the projects i work with is almost all binary... it is mostly texture files for 3D models... think liveries for aircraft... a while back, we had to basically restart the repo all over again because it was so large with
    the revisions made on all the texture files over time...

    another project that i'm aware of keeps no code in their repo... only binary archives of the project... they have to do something at times to trim things down and i think they've also had to restart the repo over a few times
    because of the size...

    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...

    TTBOMUA: one thing i find very interesting with git is that the starting repo contains no actual project files... only diffs... clones and forks do have the project files because they are recreated for each... you can take a
    back up of the initial raw .git directory, place it somewhere reachable, and clone/fork it to recreate the project if needed... for example, that one big project i work with... the raw .git repos are 16Gig in size but all of
    the repos with the sources are roughly 2Gig in size... the raw repo is larger because it contains 20 years of the project and i can go back to any point in time in them as long as i know the commit id...

    i don't understand the math involved but it is pretty neat stuff... kinda like the check files on binary news groups... you get as many of the check files you can... run them through a utility and if you have enough of the
    check files, it will recreate the original file... there's enough data in the check files that even if you miss some of them, the original file can still be fully recreated...


    )\/(ark

    ---
    ■ Synchronet ■ The SouthEast Star Mail HUB - SESTAR
  • From Rampage@VERT/SESTAR to Digital Man on Fri Aug 28 12:40:50 2020
    Re: Re: GitHub
    By: Digital Man to Gamgee on Thu Aug 27 2020 14:05:12


    Previously, with CVS, it was *much* easier to accidentally lose configuration/customization via a repository update.

    i can attest to that! :blush:


    )\/(ark

    ---
    ■ Synchronet ■ The SouthEast Star Mail HUB - SESTAR
  • From Gamgee@VERT/PALANT to Rampage on Fri Aug 28 11:56:00 2020
    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 ;)

    You're right, that's what I'm gonna do. ;)

    remember, as sysops, we specialize in automating everything via
    scripts O:)

    Hehe, well some more than others... :)



    ... 2 + 2 = 5 for extremely large values of 2.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Nightfox@VERT/DIGDIST to Gamgee on Fri Aug 28 12:26:48 2020
    Re: Re: GitHub
    By: Gamgee to Nightfox on Fri Aug 28 2020 08:02 am

    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?

    I really don't know how most other Synchronet sysops run their BBS.. But I've been running mine in Windows, and I started with the 3.13 installer for Windows and upgraded from there with the upgrade packages that have been released (as zip files). I've never needed to run my BBS from the CVS repo.. And for Windows, normally I wouldn't have even needed to check out the CVS repo, except that I've contributed some stuff to it.

    I have seen in the instructions for *nix that it said to download the CVS repo and build it, so perhaps it's easy on Linux to just run it from there, but normally I don't think that should be the case.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@VERT/DIGDIST to Gamgee on Fri Aug 28 12:35:59 2020
    Re: Re: GitHub
    By: Gamgee to Nightfox on Fri Aug 28 2020 08:02 am

    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... :(

    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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Gamgee@VERT/PALANT to Digital Man on Fri Aug 28 12:36:00 2020
    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?

    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).

    Understood.

    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.



    ... Internal Error: The system has been taken over by sheep at line 19960
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Digital Man on Fri Aug 28 12:43:00 2020
    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...

    Previously, with CVS, it was *much* easier to accidentally lose configuration/customization via a repository update.

    Yep, I never actually made that mistake, but understand.

    Thanks.



    ... So easy, a child could do it. Child sold separately.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Tracker1@VERT/TRN to alterego on Fri Aug 28 15:06:45 2020
    On 8/26/2020 5:48 PM, alterego wrote:
    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...

    With the change to git, the practice is to have source in /sbbs/repo,
    and copy the pieces out you want to update (other than what builds and
    drops into /sbbs/exec/)...

    I try to keep my changes limited to mods, text, ctrl.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Gamgee on Fri Aug 28 15:10:18 2020
    On 8/26/2020 6:59 PM, Gamgee wrote:

    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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Gamgee on Fri Aug 28 15:12:22 2020
    On 8/26/2020 7:05 PM, Gamgee wrote:

    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.

    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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Gamgee on Fri Aug 28 15:17:50 2020
    On 8/27/2020 5:40 AM, Gamgee wrote:

    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.

    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.


    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Fri Aug 28 15:20:20 2020
    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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Rampage on Fri Aug 28 15:32:14 2020
    On 8/28/2020 5:39 AM, Rampage wrote:

    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...

    That's what GitLFS was created for... it basically stores the binaries
    in a separate access point, and only updates pointer hashes for binary
    types. Unfortunately adding it to an existing repo is a little bit of a
    pain and/or requires overwritting history for the binary types, which
    will put anyone else out of sync... so it's harder to coordinate.

    If you setup LFS for your binary types in .gitattributes from the start
    (and git lfs init), it tends to go smoother.

    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...

    Should be easy enough to script, assuming /sbbs/repo is the repo
    location and /sbbs/exec is clear to overwrite for updates (using
    /sbbs/mods makes this easier). Similar for text.dat changes, I tend to override via JS, not editing text.dat directly.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Fri Aug 28 15:36:33 2020
    On 8/28/2020 8:35 AM, Nightfox wrote:

    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.

    Each commit has a unique hash assigned to it, this is effectively a
    bookmark. A branch is a list of hashes as a history of changes. A
    "tag" is a bookmark to a specific commit hash.

    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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From DaiTengu@VERT/ENSEMBLE to alterego on Fri Aug 28 17:12:58 2020
    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.




    DaiTengu

    ... You can tune a piano, but you can`t tuna fish.

    ---
    ■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
  • From DaiTengu@VERT/ENSEMBLE to Digital Man on Fri Aug 28 17:58:23 2020
    Re: Re: GitHub
    By: Digital Man to Gamgee on Thu Aug 27 2020 02:05 pm

    Previously, with CVS, it was *much* easier to accidentally lose configuration/customization via a repository update.

    Yeah, CVS would just overwrite something seemingly at random, or insert merge data into a file (in the case of a modified text.dat), that caused everything to bork up.

    Git's better with merging, and MUCH better with warning you about those merges.

    DaiTengu

    ... It is a good thing for an uneducated man to read books of quotations.

    ---
    ■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
  • From Digital Man@VERT to Gamgee on Fri Aug 28 20:34:19 2020
    Re: Re: GitHub
    By: Gamgee to Nightfox on Fri Aug 28 2020 08:02 am

    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?

    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

    Sling Blade quote #15:
    Doyle Hargraves: What'cha doin' with that lawn mower blade Karl?
    Norco, CA WX: 89.7°F, 27.0% humidity, 14 mph NNW wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Rampage on Fri Aug 28 20:37:26 2020
    Re: Re: GitHub
    By: Rampage to Digital Man on Fri Aug 28 2020 08:39 am

    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...

    Yup. Although there is a solution (https://git-lfs.github.com/), we don't need it becasue we don't have frequently changing binary files.


    digital man

    Sling Blade quote #6:
    Karl: he should've had a chance to grow up. He would had fun some time.
    Norco, CA WX: 89.7°F, 27.0% humidity, 14 mph NNW wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Gamgee on Fri Aug 28 20:41:23 2020
    Re: Re: GitHub
    By: Gamgee to Digital Man on Fri Aug 28 2020 08:36 am

    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.

    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.

    digital man

    This Is Spinal Tap quote #14:
    The Boston gig has been cancelled. [Don't] worry, it's not a big college town. Norco, CA WX: 89.2°F, 29.0% humidity, 17 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Gamgee on Fri Aug 28 20:43:02 2020
    Re: Re: GitHub
    By: Gamgee to Digital Man on Fri Aug 28 2020 08:43 am

    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?

    Correct.

    Just do the updates (git pull) into
    there, recompile, and restore custom stuff to /sbbs/text...

    Sounds good.

    digital man

    Synchronet/BBS Terminology Definition #46:
    KD = King Drafus (Allen Christiansen)
    Norco, CA WX: 89.2°F, 29.0% humidity, 17 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Tracker1 on Fri Aug 28 20:47:00 2020
    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.

    digital man

    Synchronet/BBS Terminology Definition #84:
    XJS = External JavaScript (SSJS embedded within HTML/CSS)
    Norco, CA WX: 89.2°F, 29.0% humidity, 17 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to DaiTengu on Fri Aug 28 20:50:56 2020
    Re: Re: GitHub
    By: DaiTengu to alterego on Fri Aug 28 2020 01:12 pm

    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.

    digital man

    This Is Spinal Tap quote #37:
    David St. Hubbins: We are Spinal Tap from the UK - you must be the USA!
    Norco, CA WX: 89.2°F, 29.0% humidity, 17 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From DaiTengu@VERT/ENSEMBLE to Digital Man on Fri Aug 28 23:17:25 2020
    Re: Re: GitHub
    By: Digital Man to DaiTengu on Fri Aug 28 2020 04:50 pm

    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. :-)

    I could probably script something out in bash to automagically do most of that. The real issue is getting the current locally modified files merged into your initial git clone.

    Probably could write some js script that will automatically add all your mail and file directories to .gitignore. THe most problematic bit would likely be the xtrn directory, as I'm not sure I want 50 more door games checked in, even if it is a local repo, because a lot of that data is binary.

    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.

    Definitely. I'm lucky, because I wind up using git nearly every day. Today I got to scream at a whole bunch of people for not checking in critical changes on our Stacki server (a tool for automated bare metal provisioning), and had the privilege of spending 2 hours manually merging stuff into git. <sigh>

    Maybe if I get some time next week, I can start the process of moving my install over to git. I'll try to document what I do along the way and toss it on the wiki. Probably with a big warning that says "Don't do this" :)

    DaiTengu

    ... A self-starting oscillator won't.

    ---
    ■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
  • From Nightfox@VERT/DIGDIST to Tracker1 on Fri Aug 28 23:07:24 2020
    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?

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@VERT/DIGDIST to Tracker1 on Fri Aug 28 23:09:00 2020
    Re: Re: GitHub
    By: Tracker1 to Nightfox on Fri Aug 28 2020 11:36 am

    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.

    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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@VERT/DIGDIST to Tracker1 on Fri Aug 28 23:19:55 2020
    Re: Re: GitHub
    By: Tracker1 to Gamgee on Fri Aug 28 2020 11:12 am

    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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@VERT/DIGDIST to Digital Man on Fri Aug 28 23:24:09 2020
    Re: Re: GitHub
    By: Digital Man to Tracker1 on Fri Aug 28 2020 04:47 pm

    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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man@VERT to Nightfox on Fri Aug 28 23:53:49 2020
    Re: Re: GitHub
    By: Nightfox to Tracker1 on Fri Aug 28 2020 07:07 pm

    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?

    It'd have to be when someone logs in. Call bbs.replace_text() for the lines you want to replace.

    digital man

    Synchronet "Real Fact" #93:
    Synchronet v3.17b was released on January 1 of 2019 (4 years after v3.16c). Norco, CA WX: 78.0°F, 53.0% humidity, 4 mph ENE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Digital Man on Fri Aug 28 23:57:02 2020
    Wow! 117 posts and counting....

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tracker1@VERT/TRN to Gamgee on Fri Aug 28 18:08:38 2020
    On 8/28/2020 6:43 AM, Gamgee wrote:

    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...

    Yes... for the most part, you probably only need to update /sbbs/exec
    with new files from /sbbs/repo/exec and from the compiled binaries that
    should also be deployed to /sbbs/exec, and as long as you keep your
    changes in /sbbs/mods, you should be safe.

    I tend to go a step further, and don't modify my text.dat directly, but
    use JS to set changes, then I can keep /sbbs/ctrl/text.dat unmodified as
    well.

    I reference '../mods/.../*.(ans|asc|msg...)' for my display files now as
    well, so all my customizations don't interfere with the defaults.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From MRO@VERT/BBSESINF to Tracker1 on Sat Aug 29 17:22:02 2020
    Re: Re: GitHub
    By: Tracker1 to Nightfox on Fri Aug 28 2020 11:20 am

    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.



    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. ---
    ■ Synchronet ■ ::: BBSES.info - free BBS services :::
  • From MRO@VERT/BBSESINF to Nightfox on Sat Aug 29 17:22:51 2020
    Re: Re: GitHub
    By: Nightfox to Tracker1 on Fri Aug 28 2020 07:07 pm


    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


    it's whenever it is called in a login or menu script and until they log out or it's reverted.
    ---
    ■ Synchronet ■ ::: BBSES.info - free BBS services :::
  • From Gamgee@VERT/PALANT to Tracker1 on Sun Aug 30 01:28:00 2020
    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.

    Yes, I've crawled up the learning curve a short ways, and I
    believe that git will work for me, eventually. Just had some
    conceptual things to get straight, but it's making more sense
    already. Thanks.



    ... So easy, a child could do it. Child sold separately.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Tracker1 on Sun Aug 30 01:29:00 2020
    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...

    Well, I learned enough CVS to be able to update SBBS, yes. Mostly
    by copying/using the commands given on the wiki.

    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.

    Yep, I'm finally getting that. I'm sometimes slow, but I'm
    thorough... ;-)



    ... Gone crazy, be back later, please leave message.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Tracker1 on Sun Aug 30 01:31:00 2020
    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.

    No worries. I'm quite difficult to offend. :-)

    `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.

    Thank you.



    ... Backup not found: (A)bort (R)etry (P)anic
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Digital Man on Sun Aug 30 01:33:00 2020
    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.

    OK, understood.

    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.

    Got it. Again, thank you.



    ... Nothing is so smiple that it can't get screwed up.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Digital Man on Sun Aug 30 01:39:00 2020
    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?

    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.

    Oh, I'm not going anywhere. :-)



    ... Internal Error: The system has been taken over by sheep at line 19960
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to MRO on Sun Aug 30 02:06:00 2020
    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.

    Well, you and The Millionaire have a lot in common, after all.

    Wait a minute...... ARE YOU REALLY THE MILLIONAIRE??? WHICH OF
    YOU IS REAL AND WHICH IS THE SOCK PUPPET???



    ... Warning! Error in REALITY.SYS! Proceeding with BIGBANG.EXE
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Digital Man@VERT to Gamgee on Sun Aug 30 00:53:18 2020
    Re: Re: GitHub
    By: Gamgee to Digital Man on Sat Aug 29 2020 09:39 pm

    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?

    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.


    digital man

    This Is Spinal Tap quote #4:
    David St. Hubbins: He died in a bizarre gardening accident...
    Norco, CA WX: 68.1°F, 73.0% humidity, 5 mph ESE wind, 0.00 inches rain/24hrs

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Gamgee on Sun Aug 30 22:28:00 2020
    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?

    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
    eet.


    ... Money isn't everything, usually it isn't even enough.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to Digital Man on Sun Aug 30 11:56:00 2020
    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.

    All right, that makes perfect sense, thank you. Careful, I may be
    starting to understand this... :-)

    I think the updating instructions on the Wiki need a few more
    touch-ups... ;-)

    Appreciate it!



    ... Toto, I don't think we're in DOS any more...
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Tony Langdon on Sun Aug 30 11:59:00 2020
    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.

    Yep, understood. I will probably stop using the symlinks too,
    once I get up the nerve to update from git.

    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).

    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.



    ... Forbidden fruit is responsible for many a bad jam.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Tony Langdon@VERT to Gamgee on Tue Sep 1 00:18:00 2020
    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.

    I don't think it will be a big deal, provided we use the /sbbs/repo approach.

    "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.

    Nope, we're not trying to run a BBS on a few MB anymore. :)

    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.

    You're welcome! ;)


    ... If silly had wings, this place would be an airport!
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Tracker1@VERT/TRN to Digital Man on Mon Aug 31 20:51:46 2020
    On 8/28/2020 4:47 PM, Digital Man wrote:
    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.

    Never really used CVS nearly as much as TFVC or SVN, and mostly with
    Visual Studio integration (or TortoiseSVN) and locking was part of that workflow... been mostly git for close to a decade now though.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Mon Aug 31 20:56:09 2020
    On 8/28/2020 7:07 PM, Nightfox wrote:
    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 have login override the entries used for login.. same for logon and
    for my shell.

    For reference, here's a file with all the defaults... but would probably
    just specifically change what you need/want changed, closer to where it
    lives.

    https://gist.github.com/tracker1/e8abd1672c87205b86e80579a618fb09

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Mon Aug 31 20:58:03 2020
    On 8/28/2020 7:09 PM, Nightfox wrote:
    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.

    That's true, but then integrating updates may become harder... imo,
    probably best to leave the repo directory pretty much as-is so you can
    bring down updates, then copy binaries, exec, xtrn and a few other bits
    to the running version.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Mon Aug 31 21:04:10 2020
    On 8/28/2020 7:19 PM, Nightfox wrote:
    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.

    For ammended commits, you need to generally be in a branch you made, and
    do a --force on the push as an ammended commit is re-writing history.

    I tend to squash my commits into a single commit a few times a day while working (or --amend)... then I'll `git pull --rebase origin master`
    which will pull the commits to master ahead of my own, and with the
    changes as a single commit, I only have one set of potential conflicts
    to deal with. Then another force push, or create a new branch just in
    case and push.

    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.

    Branching/merging/locks with CVS and SVN always felt more painful to me
    than how git works. It took some learning in terms of how to deal with
    it, but in general it's been pretty sweet. The server tools for github, gitlab and azure devops do improve the workflow, and they're generally
    similar to each other.

    Git is made to be able to work/commit detached. You can setup a remote
    repo with a plain SSH account with SFTP supported even, if you want a
    backup target.

    What's really cool, is there are deployment systems (like dokku) where
    you can simply do a git push and your app is up on the server in
    seconds. Hooks/pipelines/workflows for the server in different systems
    are varied though similar.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Mon Aug 31 21:06:29 2020
    On 8/28/2020 7:24 PM, Nightfox wrote:
    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.

    CVS, SVN and TFVC (Team Foundation Server Version Control, before Git
    was added) all support that checkout workflow. And yeah, it can be
    painful at times. I really don't miss it.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to MRO on Mon Aug 31 21:10:26 2020
    On 8/29/2020 11:22 AM, MRO wrote:
    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.

    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
  • From The Millionaire@VERT to Tracker1 on Tue Sep 1 08:52:58 2020
    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


    Well I’m used to editing my text.dat. Sort of force of habit, I suppose.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From The Millionaire@VERT to Tracker1 on Tue Sep 1 08:54:33 2020
    138 posts so far. Incredible.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to Tracker1 on Tue Sep 1 12:49:00 2020
    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.



    ... Computer Hacker wanted. Must have own axe.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Ragnarok@VERT/DOCKSUD to The Millionaire on Tue Sep 1 18:15:07 2020
    El 1/9/20 a las 08:54, The Millionaire escribió:
    138 posts so far. Incredible.

    and github is not used

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From Nightfox@VERT/DIGDIST to Tracker1 on Tue Sep 1 16:26:41 2020
    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.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Tracker1@VERT/TRN to Gamgee on Tue Sep 1 18:29:47 2020
    On 9/1/2020 6:49 AM, Gamgee wrote:
    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.

    // 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.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Tracker1@VERT/TRN to Nightfox on Tue Sep 1 18:32:28 2020
    On 9/1/2020 12:26 PM, Nightfox wrote:
    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.

    The time in question is less than the render latency in a remote user connection, so not really a concern. Unless you're literally replacing
    every entry on every user interaction, it's not really a big deal.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS

    ---
    Synchronet Roughneck BBS - coming back 2/2/20
  • From Gamgee@VERT/PALANT to Tracker1 on Tue Sep 1 22:59:00 2020
    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");

    OK, that makes sense to me, but again... I didn't know that
    "command" (bbs.replace_text) existed, and don't know how I could
    ever find out that it existed. Then, I'd have to know where to
    put it in the file. I'd hazard a guess that 95%+ of SBBS sysops
    are in the same boat.

    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.

    Got it, that makes sense.

    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.

    Understood again. I'm only pointing out things that strike me
    sometimes, such as the programmers in the crowd take for granted.
    Most of us are NOT programmers, and yes, anything is easy once you
    know it. Could I learn JavaScript? Yes, I'm positive I could.
    It's just that I have too many other things going on, and cannot
    take the time needed for that. I certainly don't mean any offense
    to you or any other programmers, just that sometimes things are
    suggested that are just not realistic for most of us. Thanks for
    explaining all that to me, I do appreciate it.



    ... So easy, a child could do it. Child sold separately.
    --- MultiMail/Linux v0.52
    ■ Synchronet ■ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From The Millionaire@VERT to Digital Man on Thu Sep 3 10:28:23 2020
    146 posts. Unbelievable.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Ragnarok@VERT/DOCKSUD to The Millionaire on Thu Sep 3 16:07:06 2020
    El 3/9/20 a las 10:28, The Millionaire escribió:
    146 posts. Unbelievable.

    147

    ---
    ■ Synchronet ■ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
  • From echicken to The Millionaire on Thu Sep 3 15:42:09 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Thu Sep 03 2020 06:28:23

    146 posts. Unbelievable.

    Don't strain your wrist over there. Try switching hands once in a while. Consider using a lubricant.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
  • From DaiTengu@VERT/ENSEMBLE to The Millionaire on Thu Sep 3 20:08:19 2020
    Re: Re: GitHub
    By: The Millionaire to Tracker1 on Tue Sep 01 2020 04:54 am

    138 posts so far. Incredible.

    And only 3 on topic, all yours.

    DaiTengu

    ... I belong to no organized party - I am a democrat.

    ---
    ■ Synchronet ■ War Ensemble BBS - The sport is war, total war - warensemble.com
  • From DaiTengu@VERT/ENSEMBLE to The Millionaire on Thu Sep 3 20:11:35 2020
    Re: GitHub
    By: The Millionaire to Digital Man on Thu Sep 03 2020 06:28 am


    146 posts. Unbelievable.

    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
  • From The Millionaire@VERT to DaiTengu on Thu Sep 3 23:59:08 2020
    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


    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 *****.

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From DaiTengu@VERT/ENSEMBLE to The Millionaire on Fri Sep 4 13:02:16 2020
    Re: The Millionaire is a nuisance
    By: The Millionaire to DaiTengu on Thu Sep 03 2020 07:59 pm

    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 *****.

    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
  • From The Millionaire@VERT to DaiTengu on Fri Sep 4 12:27:50 2020
    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


    “I like you. You make me laugh.” - Gung Ho

    $ The Millionaire $

    ..."Will we ever fear the ecstasy of free thought?" - Thinkman...

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net