Hey DM,
Have you considered switching to git? I'm just curious.
I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.
...ëîå*
... A day for firm decisions!!!!! Or is it?
---
¨ Synchronet ¨ Alterant | an SBBS in Docker on Pi!
Hey DM,
Have you considered switching to git? I'm just curious.
I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.
There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
The reason I haven't switched the main development repo to git is the lack of a revision number in git. With CVS, I can ask you to read the $Id tag of a file or send the relevant log message and I can know
*exactly* what revision of that file you have/are-running (and how old it is). With git, that's way more complicated.
Re: GIT
By: Digital Man to Alterego on Sun Sep 01 2019 09:22 pm
There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
Hmm... a bit :)
The reason I haven't switched the main development repo to git is the lack of a revision number in git. With CVS, I can ask you to read the $Id tag of a file or send the relevant log message and I can know *exactly* what revision of that file you have/are-running (and how old it is). With git, that's way more complicated.
Shame, have you considered that the build could add the hash of the checkout?
IE: sbbs -h could say "SBBS v3.17c abcd1234", where abcd1234 is the hash of the checkout used during the build?
That way its quite easy to see what
version everything is at, and what has changed since. (And to branch at the hash to reproduce the issue, fix, and merge it back into master).
It wouldnt be "normal" that somebody just checks out a part of SBBS and uses it (even to compile) right?
Ideally, if you updated a component (lets say
binkit), you ideally should update everything else, especially if binkit is dependant on changes in other files as well?
Git handles sub modules well as well, so you could be working on a sub module and committing changes, then updating master (to use the updated submodule) when its ready...
Sorry, just thinking aloud - but I think it would be good to see git being used, only because my brain cells that remembered cvs have long gone - and I'd love to explore your code for some ideas I have... ;)
Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the
revision you have of that file is newer than the revision which includes the fix for the problem being discussed.
Ideally, but that rarely happens. And, the updated JS and .src files usually do not require the absolete latest executables built from the C/C++ code.
It's quite frequent that sysop only update some of their files. Or even if they've updated their source files, maybe they forgot to rebuild them or they
ran differnet binaries than the ones they last built. All kinds of scenarios.
Git handles sub modules well as well, so you could be working on a sub module and committing changes, then updating master (to use the updated
submodule) when its ready...
I don't see how that's relevant to the revision number issue. Sub modules bring their sets of problems anyway.
I'm not sure how git changes how you (or anyone else) can explore the code. The files are on your disk. If you want a web inteface to the source files,
goto cvs.synchro.net.
Re: GIT
By: Digital Man to Alterego on Mon Sep 02 2019 01:11 am
Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the revision you have of that file is newer than the revision which includes the fix for the problem being discussed.
I guess I dont understand your thinking. I've certainly used CVS before and currently use git, and I find supporting downstream users far easier with a git environment (and that use case is well used). IE: By knowing what hash or tag they've checked out, I know what their source enviroment looks (or should) look like.
Have you considered switching to git? I'm just curious.
I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.
A lot of source is going git lately I hear. It's supposed to be the new sourceforge.
Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the
revision you have of that file is newer than the revision which includes the fix for the problem being discussed.
I guess I dont understand your thinking. I've certainly used CVS before and currently use git, and I find supporting downstream users far easier with a git environment (and that use case is well used). IE: By knowing what
hash or tag they've checked out, I know what their source enviroment looks (or should) look like.
Re: GIT
By: Alterego to Digital Man on Mon Sep 02 2019 12:42 pm
Hey DM,
Have you considered switching to git? I'm just curious.
Yup.
I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.
There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
https://github.com/W8BSD/SBBSUnstable
you're thinking of the snapshot hash of the entire source tree... so what happens if i go in and manually grab the source to (eg) binkit by copying the
source from the view window (copy'n'pasta) instead of using git to grab it? i've now got the/some source for binkit that is behind or beyond the current
hash my system carries... if i have problems and you ask for the hash, i give it to you but my binkit sources do not match with the binkit sources in
that hash... if there was an automated method to assign and increment a version number inside each file, you would know immediately where the problem
resides... can you see the problem now?
you're thinking of the snapshot hash of the entire source tree... so
what happens if i go in and manually grab the source to (eg) binkit
by copying the source from the view window (copy'n'pasta) instead of
using git to grab it? i've now got the/some source for binkit that is
behind or beyond the current hash my system carries... if i have
problems and you ask for the hash, i give it to you but my binkit
sources do not match with the binkit sources in that hash... if there
was an automated method to assign and increment a version number
inside each file, you would know immediately where the problem
resides... can you see the problem now?
Actually, no not really.
I understand what you are doing - you are cherry-picking individual files
to use. I dont understand why you would only cherry pick individual
files.
(And therefore DM wants to know what version of a cherry-picked file
you have got.)
Is it to save rebuilding time? If nothing else changed, then there
wouldnt be any rebuild (or it would be minimal). But if other things changed needing a rebuild, wouldnt you want to get those updates as
well?
If something is truely independant of the core code base - that is
being developed (and consumed) at a different rate then the core, then
it could be a submodule. Although, I'm not saying every individual cherrypickable file should be a sub module (I know that doesnt work
for may reasons).
Anyway, I think I get whats going on - and I know everybody does
things a differently, for their different reasons - I respect that
Have you considered switching to git? I'm just curious.
I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc. ...ëîå*
A lot of source is going git lately I hear. It's supposed to be the new sourceforge.
My team at work just started using Git a couple years ago (we were using SVN before that). In some ways, I still feel like I'm getting used to git. My biggest frustration is still when I want to push up
one of my commits and there are merge conflicts with other changes. From what I understand, I think the best way to deal with that is to do a 'git fetch' and a 'git rebase' and fix any merge conflicts with
the rebase, and then amend any commits I currently have. But sometimes it seems like there are still problems. Sometimes when I do a 'git fetch' or 'git pull', it merges in another branch.. I'm sometimes
unsure of the state of my local copy after that, so sometimes I've resorted to pulling a fresh copy of the repo/branch.
There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
https://github.com/W8BSD/SBBSUnstable
This repo from Deuce are update , but two weeks ago, lost sync.
https://github.com/RealDeuce
Re: GIT
By: Rampage to Alterego on Mon Sep 02 2019 08:01 am
you're thinking of the snapshot hash of the entire source tree... so what happens if i go in and manually grab the source to (eg) binkit by copying the
source from the view window (copy'n'pasta) instead of using git to grab it? i've now got the/some source for binkit that is behind or beyond the current
hash my system carries... if i have problems and you ask for the hash, i give it to you but my binkit sources do not match with the binkit sources in
that hash... if there was an automated method to assign and increment a version number inside each file, you would know immediately where the problem
resides... can you see the problem now?
Actually, no not really.
I understand what you are doing - you are cherry-picking individual files to use. I dont understand why you would only cherry pick individual files. (And therefore DM wants to know what version of a cherry-picked file you have got.)
Is it to save rebuilding time? If nothing else changed, then there wouldnt be any rebuild (or it would be minimal). But if other things changed needing a rebuild, wouldnt you want to get those updates as well?
Re: GIT
By: Alterego to Digital Man on Mon Sep 02 2019 12:42 pm
Have you considered switching to git? I'm just curious.
I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc. ...ëîå*
My team at work just started using Git a couple years ago (we were using SVN before that). In some ways, I still feel like I'm getting used to git. My biggest frustration is still when I want to push up one of my commits and there are merge conflicts with other changes. From what I understand, I think the best way to deal with that is to do a 'git fetch' and a 'git rebase' and fix any merge conflicts with the rebase, and then amend any commits I currently have. But sometimes it seems like there are still problems. Sometimes when I do a 'git fetch' or 'git pull', it merges in another branch.. I'm sometimes unsure of the state of my local copy after that, so sometimes I've resorted to pulling a fresh copy of the repo/branch.
Do you work on your contributions in your own branch locally?
The majority of Synchronet sysops run the Windows versions which they do not rebuild themselves, so they really don't even need to bother updating the C/C++ source files (but they often do want the latest
revision of others files). But I can (with CVS) ask them or even check for myself what revision of webservr.c or mailsrvr.c that they're running and know very easily if that revision includes some change of
note (or not). With a hash, I don't get that. I'd have to find that hash in a git log and then compare its date against the date of hash of interest.
With incrementing revision numbers, I can just say, hey you need rev 1.287 or later for that fix and it's obvious to everyone what that means. If I said you need rev EA9BC2F or later, that's not very
helpful. Perhaps they *already* have a revision later than EA9BC2F, but how would they know? They wouldn't, again, without carefully examining a git log.
I'm sure there would be an answer to your questions using git, as well as you probably dont have any compelling reason to change from CVS. If it aint broke dont fix it right?
I feel ya. Even when think I have a good grasp of git, I sometimes get into states where I'm like: how'd that happen?
And many times when trying to help junior co-workers, I'd be befuddled about how they got their local repo into the state its in.
Here's some tips that've helped me with using git:
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 173:40:16 |
| Calls: | 509 |
| Messages: | 220412 |