+- UserSpice (https://userspice.com/forums)
+-- Forum: Miscellaneous (https://userspice.com/forums/forumdisplay.php?fid=28)
+--- Forum: Off-topic Discussions (https://userspice.com/forums/forumdisplay.php?fid=10)
+--- Thread: Moving to github (/showthread.php?tid=291)
Moving to github - plb - 09-30-2016
Have y'all ever considered moving all your source code into github (or another similar)? It would make life so much easier in terms of keeping bug fixes updated in each minor release, ease moving new features developed in an earlier release into the latest release, etc.
For example, I am ready to move forward on nested groups. But should I do it on 4.4 or 5.0? The easy answer is 5.0,but I don't want to wait for 5.0 release. So I develop it in stable 4.4 but how will it get into 5.0 without a horrendous, manual process of editing the changes into the new code 1 by 1.
Another example. I messed around with db.php and then wanted to upgrade to the next release. If it was in github it would simply be a question of checking out the next version and letting it handle the merging of changes. If there are conflicts then it tells you and you have to do the laborious manual editing, but with access to some tools that help...
Thoughts? Or maybe y'all already have it in some other source code mgmt system...?
Moving to github - mudmin - 09-30-2016
It's all on github now...at least full releases. I haven't put 4.2 alpha stuff on there.
https://github.com/mudmin/UserSpice4
Here are all the individual releases.
https://github.com/mudmin/UserSpice4/commits/master
Moving to github - brian - 09-30-2016
I simply don't have a clue how to make Git do something useful. If you can give a good tutorial or something on how to make this work, then sure. I'm not a software guy. I'm a hardware guy that is like a curious cat minus a few lives. I make software do what I need it to. This is the first multi-person bit of software that I've worked on. We've just been passing files back and forth. I've been doing some US5 stuff, while Dan is on the US4 stuff.
Moving to github - plb - 10-01-2016
This page (where you also download the default windows client) has a quick overview:
https://desktop.github.com/
(Using the command line git from the git bash console is actually a lot more flexible, but it's got a much steeper learning curve if you aren't familiar with bash)
I did a quick google of "github tutorial" and found dozens.
* http://kbroman.org/github_tutorial/ seems good for command-line
* https://www.youtube.com/watch?v=XdhuWDdu-rk is a nice 3-minute overview of the basics including a fork and a pull request
Basically you think of your source code as the "trunk of a tree". If you "sliced" the tree at any point you would be able to see a where each tube/cell/etc was at that point in the tree. (Sorry, I'm not much of a biologist, but the analogy will become important.) Each time you make a new change to a file or set of files a new copy is added - the trunk grows a bit. All previous historical revisions are always kept and any commit of a new change should always have a comment describing what the change accomplished or why it was done. So you have a log of when every change was made and you can easily grab the code as a "snapshot" of all changes as of a particular time.
If you are a single individual working on the project in a very linear fashion then that's probably all you need to know. And the benefit you would get would be simply that it keeps track of the history of the project and you can backtrack without difficulty if you find you've made a mistake or need to go back to a certain point in time. It's basically a really nice but somewhat overpowered backup system.
But if you start work on version 5.0 while you are still developing features for 4.2 and bug-fixes for 4.1.5 and 3.3 and 2.2 and 1.1 and 0.000001 then github can become your best friend.
We started with the analogy of a "tree trunk" of source code with each change being recorded linearly on top of the change that occurred before. Now we go to "branches". Let's say I want to try something with US, but I'm not sure if I'm going in a good direction - it's an experiment. I will create a new branch ("my-experiment") and check it out - now I have a full backup, an exact copy of the trunk ("trunk"="master") at the time I made the branch. It's set up in a separate folder on my computer and I can do anything I want with it.
Meanwhile someone reports a bug. If I fix it on my experimental code then I am going to be rushed into releasing something that at best isn't done and at worst isn't even something I want to do. So I check out a version of the master (the "trunk") and make the changes and check it back in.
Now I'm in the middle of developing my experiment and something goes wrong. Later I will find out that my 2-year-old played patty-cake with my keyboard while I was out, but for now all I can figure out is what was working is no longer working. In a click or 2 I can see every change made on this branch - wait! What's that patty-cake text at line 119 - I didn't do that. And suddenly it's fixed. (This also shows why it is better to make little changes at a time, committing after each change when you get to a point where things are semi-stable or fully stable -- a key concept in effective use of git.)
I finish my experiment and it's awesome! Of course the whole world will want this new feature, but I would really rather not have to implement the bug-fix that happened in between. That's OK, because when I merge my-experiment branch back into the trunk Git will check carefully if there were any conflicts (a change you made in my-experiment that took place in the same area of the same file as the bug-fix was made on the master) and if there are no conflicts then it checks everything in and your new master ("trunk") now contains both the bug-fix and my-experiment.
Now that small example begins to show the advantages of git. Now let's say that you have 3 (or 30) developers all making changes at the same time. Some changes are bug-fixes on 4.1.5 heading towards 4.1.6 but already someone else has started changes aiming towards the new features of 4.2 and someone else is thinking long-term towards 5.0. (Sound like a familiar situation?) So the bug-fix buy checks out 4.1.5, makes a new branch and fixes the problem and merges it back in. The person working on 4.2 sees that this bug-fix is needed there as well so (this is key!) they take the branch between the start of the bug-fix branch and the end of the bug-fix branch and apply it back onto the trunk heading for 4.2. The person working on 5.0 realizes that change has been completely re-worked already so doesn't bother ... or they see that it's needed and so they merge it into their copy.
Now some total newb comes in who just found US a month ago and has all kinds of hare-brained ideas. (Sound familiar again? :-) ) Write access to the main github repository would be crazy in this situation. So he just forks the whole project into his own account. Now he makes his branches, makes his changes, etc. And then he creates what's called a "Pull Request" (PR). A PR is basically the changes between one snapshot of the source code and another snapshot. And it's no problem if one snapshot is on one account (mudmin) and another is on another account (pbowers). So the newb creates a PR on the main trunk of US and the real developers are thus (by means of the PR) notified that there is a proposed change.
(Think of all the pastebins that I've been putting out there. Instead of a pastebin I would have created a branch on my forked copy of US and then submitted a PR for you to look at. You could have chosen to look at the PR as either diff output or as the actual source code files that I've submitted.)
If the US developers look at the change and evaluate it and agree that it's a good contribution then they merge it into whichever branch(es)/trunk is appropriate and close the PR. If they don't like it then they just comment on the PR and close it. These PRs become the primary way the open source community of volunteer developers contribute to the project.
Moving to github - brian - 10-01-2016
Wow, pretty detailed. I'll need to read through it in detail again. How do things like files with credentials stored in them work? Can you set permanent exclusions to make sure that type of stuff doesn't get uploaded?
Moving to github - plb - 10-02-2016
I had never tried it, but there are apparently several ways:
https://help.github.com/articles/ignoring-files/
Probably creating a global .gitignore (probably everybody wants to not checkin init.php, for instance) makes the best sense, but there are lots of options there.
Of course the simplest option is simply not to check it in, but being able to "checkin all" is a timesaver...
Moving to github - brian - 10-02-2016
Part of this gets solved because UserSpice 5 moves the DB credentials to a separate file (so easy to ignore I suppose). That way init is focused more on the page initialization, and the rest of keys and things are in the database.
Moving to github - plb - 10-02-2016
I know there was some mention somewhere (?) of moving most of configuration into the DB.
With the current contents of init.php (even if DB credentials are removed) you would certainly not want someone to check in their own personal copy - it seems like it is basically dynamically created during the installation process and so is quite unique to each installation as far as I can tell.
Moving to github - brian - 10-02-2016
The goal is to eliminate customization from init.php all together. That way the installation will pretty much be 4 steps (and probably 1 or two pages).
1) Input your DB credentials
2) Write DB credential file
3) Test DB Connection/Import DB
4) Done
There won't be any need for the current chunk prep during installation so it should be cleaner and faster.
But yes, this way, more stuff can be changed or modified in the init.php if anyone finds probablems there.
Moving to github - plb - 10-04-2016
Some pretty big-name projects still use php-script-based configuration for at least a portion of their configuration. THere are some things that are just easier to do in PHP than in the DB...
For instance, I just added a 'userspice/admin_groups' and it is set as an array. You *can* make this work within the DB, but to make sure the user enters the data appropriately you're going to have to write a special form with appropriate validation and etc. All that when they could have written "array(2,7,19)"...
The end result of having "fancy DB" configuration is that developers tend to hardcode their chosen defaults - to make it configurable is just too much of a pain. Whereas if I can write this code:
if (!$adminGroups = Config::get('userspice/admin_groups'))
$adminGroups = [2];
And not think about it anymore then I will make it a habit to *always* allow that kind of configuration override.
It may be worth thinking about leaving options open for code-based configuration...