Hello all,

Getting ready to (finally) do an update to my system since the
switch to Git... Yes, I'm slow to change...

Using Linux, and am going to do a complete reinstall, followed by copying/editing my existing config into the new one. Reason for
that is that I want to have all the latest options (new sections
in modopts.ini, sbbsecho.ini, etc...), and a "clean" start.

Not worried about the actual install and re-config. Planning
to use the SYMLINKS method also. I understand about putting
modified JS/Baja stuff in /sbbs/mods, so that changes don't get
wiped out when doing a Git update (to exec) later. Again no
problem.

So, here's what I am wondering about. The /sbbs/text directory
will also be symlinked (to /sbbs/repo/text). I have a lot of
custom menu/display files in /sbbs/text/menu. Will Git see those
as "conflicts" when I do the "git pull" thing to update later?
Will I have to do all that merge/push/pop/stash stuff to deal with
that, or not? That's my last remaining concern after reading and
studying this new procedure... Thanks for info.



... Nothing is so smiple that it can't get screwed up.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Updating to/via Git
By: Gamgee to All on Sun Oct 25 2020 12:00 pm

Hello all,

Getting ready to (finally) do an update to my system since the
switch to Git... Yes, I'm slow to change...

Using Linux, and am going to do a complete reinstall, followed by copying/editing my existing config into the new one. Reason for
that is that I want to have all the latest options (new sections
in modopts.ini, sbbsecho.ini, etc...), and a "clean" start.

You could just copy those files, but honestly, there's nothing new in sbbsecho.ini (and echocfg always re-writes all the new keys anyway). I don't recommend a "complete reinstall".

Not worried about the actual install and re-config. Planning
to use the SYMLINKS method also. I understand about putting
modified JS/Baja stuff in /sbbs/mods, so that changes don't get
wiped out when doing a Git update (to exec) later. Again no
problem.

So, here's what I am wondering about. The /sbbs/text directory
will also be symlinked (to /sbbs/repo/text). I have a lot of
custom menu/display files in /sbbs/text/menu. Will Git see those
as "conflicts" when I do the "git pull" thing to update later?
Will I have to do all that merge/push/pop/stash stuff to deal with
that, or not? That's my last remaining concern after reading and
studying this new procedure... Thanks for info.

If you have a lot of customizations in your text dir, then you could use copies , rather than symlinks of the repo/text files (probably preferred), or you could create a local branch to merge upstrea changes into, but yes, its very likely there will be conflicts - especially in the future when there's a git-change to the same line(s) of a file that you have locally modified.

Another approach would be to symlink the individual files in text (rather than the directory itself) and then break those symlinks for any files you modify. That way, your unmodified files are automatically updated on a git pull, but your modified files are excluded.
--
digital man

Synchronet "Real Fact" #31:
The Synchronet IRC server (ircd) was written in JS by Randy Sommerfeld (Cyan). Norco, CA WX: 59.0øF, 90.0% humidity, 9 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Digital wrote:

If you have a lot of customizations in your text dir, then you could use

copies , rather than symlinks of the repo/text files (probably preferred), or you could create a local branch to merge upstrea changes into, but yes, its very likely there will be conflicts - especially in the future when there's a git-change to the same line(s) of a file that you have locally modified.

Another approach would be to symlink the individual files in text (rather

than the directory itself) and then break those symlinks for any files you modify. That way, your unmodified files are automatically updated on a git pull, but your modified files are excluded.


In my experience it's been better to create a new directory under text and be designed to keeping custom versions. That way nothing gets overwritten. On my BBS I've created my own shell and made it default and the only option :)

If I stuck with Sync classic then I'd create my own version of default.src and friends since I use ansiview for the text file section.

It seems easier to have to total separation between customization and default sync stuff. That means I can overwrite all day without affecting my own changes.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Gamgee wrote to All <=-

copying/editing my existing config into the new one. Reason for
that is that I want to have all the latest options (new sections
in modopts.ini, sbbsecho.ini, etc...), and a "clean" start.

That is a tricky bit. Once a quarter I update from the .zips, then
end up with the stock .ini and my .ini side by side to compare the
two and see what new options I'm missing.

It's not a bad idea, I suppose, familiarizing me with the options.


... Remove specifics and convert to ambiguities
--- MultiMail/XT v0.52
þ Synchronet þ realitycheckBBS -- http://realitycheckBBS.org
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

poindexter FORTRAN wrote to Gamgee <=-

Gamgee wrote to All <=-

copying/editing my existing config into the new one. Reason for
that is that I want to have all the latest options (new sections
in modopts.ini, sbbsecho.ini, etc...), and a "clean" start.

That is a tricky bit. Once a quarter I update from the .zips,
then end up with the stock .ini and my .ini side by side to compare
the two and see what new options I'm missing.

Yep, that's exactly what I'm intending to do. Then copy/paste my
specifics into the new one and save.

It's not a bad idea, I suppose, familiarizing me with the
options.

Agreed.



... So easy, a child could do it. Child sold separately.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: Updating to/via Git
By: Gamgee to Digital Man on Mon Oct 26 2020 08:05 am

Digital Man wrote to Gamgee <=-

Getting ready to (finally) do an update to my system since the
switch to Git... Yes, I'm slow to change...

Using Linux, and am going to do a complete reinstall, followed by copying/editing my existing config into the new one. Reason for
that is that I want to have all the latest options (new sections
in modopts.ini, sbbsecho.ini, etc...), and a "clean" start.

You could just copy those files, but honestly, there's nothing
new in sbbsecho.ini (and echocfg always re-writes all the new
keys anyway). I don't recommend a "complete reinstall".

Okay, I may reconsider that part of it.

Not worried about the actual install and re-config. Planning
to use the SYMLINKS method also. I understand about putting
modified JS/Baja stuff in /sbbs/mods, so that changes don't get
wiped out when doing a Git update (to exec) later. Again no
problem.

So, here's what I am wondering about. The /sbbs/text directory
will also be symlinked (to /sbbs/repo/text). I have a lot of
custom menu/display files in /sbbs/text/menu. Will Git see those
as "conflicts" when I do the "git pull" thing to update later?
Will I have to do all that merge/push/pop/stash stuff to deal with
that, or not? That's my last remaining concern after reading and studying this new procedure... Thanks for info.

If you have a lot of customizations in your text dir, then you
could use copies , rather than symlinks of the repo/text files (probably preferred), or you could create a local branch to merge upstrea changes into, but yes, its very likely there will be
conflicts - especially in the future when there's a git-change to
the same line(s) of a file that you have locally modified.

I don't want to get in to the merge/push/stash stuff, but I think
I understand the first part of what you said there. Would the
following method work fine:

1. Don't use the SYMLINK method (just install). After a Git
pull, do the normal make procedure, which will put the new
executables in /sbbs/exec. No symlinks anywhere.
2. As per the "Run time files" section of the Dev Update
procedure, download and extract the daily archives of 'exec' and
'text', overwriting into /sbbs/exec and /sbbs/text.
3. Restore all my custom stuff into /sbbs/text (which was
previously backed up).
4. Download and copy the new text.dat into /sbbs/ctrl.
5. Run the ./jsexec update.

I believe that would be a good solution for me, do you see
anything wrong with those steps?

Thank you for your time and advice.

DM... just asking again about the above (the last couple of paragraphs anyway)... Wondering if you might have missed it with your recent power outage. Do you see anything inherently "wrong" with the updating method I described there? Thank you.

---
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: Updating to/via Git
By: Gamgee to Digital Man on Tue Oct 27 2020 05:49 pm

I believe that would be a good solution for me, do you see
anything wrong with those steps?

Other than being more manual than necessary, no, I don't see anything wrong with it.
--
digital man

Synchronet/BBS Terminology Definition #34:
FTS = FidoNet Technical Standard
Norco, CA WX: 57.0øF, 32.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Digital Man wrote to Gamgee <=-

Re: Re: Updating to/via Git

I believe that would be a good solution for me, do you see
anything wrong with those steps?

Other than being more manual than necessary, no, I don't see
anything wrong with it.

Okay, thanks for that, appreciate it.



... Nothing is so smiple that it can't get screwed up.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)