Yesterdays xp mess made me realize that it looks like the server code base is not under version control. Now, I'm not sure if that's the case (I surely hope that I'm wrong about it), but working without version control is a disaster of epic proportions waiting to happen (like yesterday).
In case I'm right, and there's no version control, it should be put under it ASAP.
Some tutorials:
https://www.atlassian.com/git/tutorials/
https://try.github.io/levels/1/challenges/1
http://rogerdudler.github.io/git-guide/
https://git-scm.com/docs/user-manual.html
Repository can be hosted on either bitbucket or github.
Now, bitbucket allows private repositories up to 2 GB, while github does not (not for free, anyway).
Private repo would host the files, while public one would allow other people to spot obvious scripting bugs and submit fixes. Whichever you prefer.
Just saying that identifying "what the heck went wrong" is running one command, when version control is available.
Put the server code under version control
Moderators: Moderator, Developer, DM
-
NegInfinity
- Posts: 2449
- Joined: Wed Feb 05, 2014 11:24 am
- Rasael
- Retired Staff
- Posts: 8096
- Joined: Wed Jun 30, 2010 6:52 am
- Location: Leiden, Netherlands
Re: Put the server code under version control
This wasn't code related (at all). It was a configuration issue caused by file merging.
In my experience that is a known issue even in professional circles. despite their professional version control. But its usually caught and fixed in the dev or test deployments.
We don't use gith-hub or desura because it cost us time and efficiency to administrate that. Our toolset doesn't support it. It isn't visual-studio (very regrettably). Ofcourse we have manual version control: localised previous versions we can revert back to, and compare against. And we track what is changed though each update.
Problems usually originate from the merging of other content than scripts (which are easy to track and revert). Things like 2da's, areas, quests, and journal updates. Those have to be manually merged and verified. And that means there's a margin of errors.
Managing the update process is also difficult because it has its own arcane hiccups that you have to be aware of, or it will alter your settings (for example). Kind of like DirectX programming with floating-point issues. With Luna's temporary absence we lost someone who knew all that. So this was a lesson learned in quest updates. Staff experience and knowledge is the critical issue, rather than version controlling.
Of course professional version-control is beneficial. As would be things like code-reviews and deploying in stages to development-test-release etc.. But we don't have the tools and the resources to create (and maintain: staff-turnover, burn-outs, volunteering) such a professional environment.
In my experience that is a known issue even in professional circles. despite their professional version control. But its usually caught and fixed in the dev or test deployments.
We don't use gith-hub or desura because it cost us time and efficiency to administrate that. Our toolset doesn't support it. It isn't visual-studio (very regrettably). Ofcourse we have manual version control: localised previous versions we can revert back to, and compare against. And we track what is changed though each update.
Problems usually originate from the merging of other content than scripts (which are easy to track and revert). Things like 2da's, areas, quests, and journal updates. Those have to be manually merged and verified. And that means there's a margin of errors.
Managing the update process is also difficult because it has its own arcane hiccups that you have to be aware of, or it will alter your settings (for example). Kind of like DirectX programming with floating-point issues. With Luna's temporary absence we lost someone who knew all that. So this was a lesson learned in quest updates. Staff experience and knowledge is the critical issue, rather than version controlling.
Of course professional version-control is beneficial. As would be things like code-reviews and deploying in stages to development-test-release etc.. But we don't have the tools and the resources to create (and maintain: staff-turnover, burn-outs, volunteering) such a professional environment.
-
NegInfinity
- Posts: 2449
- Joined: Wed Feb 05, 2014 11:24 am
Re: Put the server code under version control
You don't need github, you don't need desura, you don't need visual studio.Rasael wrote:This wasn't code related (at all). It was a configuration issue caused by file merging.
In my experience that is a known issue even in professional circles. despite their professional version control. But its usually caught and fixed in the dev or test deployments.
We don't use gith-hub or desura because it cost us time and efficiency to administrate that. Our toolset doesn't support it. It isn't visual-studio (very regrettably). Ofcourse we have manual version control: localised previous versions we can revert back to, and compare against. And we track what is changed though each update.
Problems usually originate from the merging of other content than scripts (which are easy to track and revert). Things like 2da's, areas, quests, and journal updates. Those have to be manually merged and verified. And that means there's a margin of errors.
Managing the update process is also difficult because it has its own arcane hiccups that you have to be aware of, or it will alter your settings (for example). Kind of like DirectX programming with floating-point issues. With Luna's temporary absence we lost someone who knew all that. So this was a lesson learned in quest updates. Staff experience and knowledge is the critical issue, rather than version controlling.
Of course professional version-control is beneficial. As would be things like code-reviews and deploying in stages to development-test-release etc.. But we don't have the tools and the resources to create (and maintain: staff-turnover, burn-outs, volunteering) such a professional environment.
You need command-line git only, which can be installed on all major platforms fairly easily.
From command-line git, repository can be optionally be uploaded to bitbucket/github or any other hosting that supports git, but even without remote hosting it will be beneficial to have local git repository.
Git can diff any text files, and store binary files as binary blobs. You can revert to any previous state of the repository in seconds, you can have multiple people working on different features at once (that works with text based assets, though).
Storing local snapshots is not a version control and it is not a substitute for version control, because you cannot branch and cannot quickly locate differences. It is a recipe for disaster.
Either way, your reply indicates that you do not have version control. I urge you to look into having it asap, because with only local snapshots, you're pretty much asking for trouble and are making your own life harder.
- Lockonnow
- Posts: 3116
- Joined: Fri Oct 15, 2010 12:10 pm
Re: Put the server code under version control
Iam glade that my home is safe so far if i dont pay the rent i will be cast out but cyberspace is like a Rp game you need to buff up and and have a lots of proection wards around ,good luck and by the way why the helll didt i get to leaning all of those thing many be i sould put me in this cyberspace thing
-
NegInfinity
- Posts: 2449
- Joined: Wed Feb 05, 2014 11:24 am
Re: Put the server code under version control
Git tutorial:
https://try.github.io/
It is not the best git tutorial, but this shoudl be enough for a developer/programmer to get started.
Also see:
https://help.github.com/articles/good-r ... nd-github/
https://try.github.io/
It is not the best git tutorial, but this shoudl be enough for a developer/programmer to get started.
Also see:
https://help.github.com/articles/good-r ... nd-github/
- Rasael
- Retired Staff
- Posts: 8096
- Joined: Wed Jun 30, 2010 6:52 am
- Location: Leiden, Netherlands
Re: Put the server code under version control
Again, the issue wasn't related to different versions of anything. Or of needing to do a content revert. It was caused by an unexpected reference which was introduced during the actual update process. The fix was to set the proper reference by repeating the update step.
You're gunning for the wrong problem (but your expertise and enthusiasm are appreciated!).
We have explored version control systems during Luna's tenure.
Luna rejected git and Desura because they don't facilitate the updating process.
The folks running this server, and the update process, are not developers or programmers (I'm not involved in it). So putting it on them to work with professional tools and maintain a professional environment doesn't simply work. It would require a significant effort on their part, and can cause equally serious issues if it goes wrong, because it disorders the known and trusted routine (a defense akin to cursing in IT, because newer is better
).
So far as I know updating requires preparing the module for staging through the NWN2 toolset, with all the appropriate merged files in the hak-packs. For the sake of the auto-downloader. With a number of necessary manual interventions because the staging tool screws your files over. Then finally you copy the necessary files onto the server from the master module. The copy-pasting is simple and doesn't cause serious issues. Everything before it does. Luna wrote more than 12 tutorials on it for Duster, just about the basics of it.
So what does Git add? Maintaining a local code repository duplicates the master module on the server without addressing what we actually have a problem with (the arcane update process). That doesn't make it a bad idea. But we already have storage-space issues on the server, where it would be most handy to have had it. And there are the mentioned issues with the developer experience of the people who would have to use those tools, the time that has to be invested, and the risk if it goes wrong.
Ofcourse Github (remote) is interesting if you have multiple developers who need to touch the same assets. Just like the Team Foundation Server (Team). But we haven't had problems with that... Nonetheless: if this were a business we'd be obliged to have have either Git or TFS. But we aren't. Fortunately we don't have nearly the same code / file base as a business either.
Sky-castles,
If we had the means and the time it'd be a great idea to setup something professional with Octopus and powershell scripting. With a local repository on the server, which we can update from the remote repository. We'd need to write a program to stage an update and merge the necessary files remotely, transfer to the server, and finally copy-paste. Shut-down sequence, start-up sequence. And to work around the arcane things the stock updater does (there are arcane things the startup sequence does too). But given the age of NWN2 that's just a sky-castle... At least for the time being.
You're gunning for the wrong problem (but your expertise and enthusiasm are appreciated!).
We have explored version control systems during Luna's tenure.
Luna rejected git and Desura because they don't facilitate the updating process.
The folks running this server, and the update process, are not developers or programmers (I'm not involved in it). So putting it on them to work with professional tools and maintain a professional environment doesn't simply work. It would require a significant effort on their part, and can cause equally serious issues if it goes wrong, because it disorders the known and trusted routine (a defense akin to cursing in IT, because newer is better
So far as I know updating requires preparing the module for staging through the NWN2 toolset, with all the appropriate merged files in the hak-packs. For the sake of the auto-downloader. With a number of necessary manual interventions because the staging tool screws your files over. Then finally you copy the necessary files onto the server from the master module. The copy-pasting is simple and doesn't cause serious issues. Everything before it does. Luna wrote more than 12 tutorials on it for Duster, just about the basics of it.
So what does Git add? Maintaining a local code repository duplicates the master module on the server without addressing what we actually have a problem with (the arcane update process). That doesn't make it a bad idea. But we already have storage-space issues on the server, where it would be most handy to have had it. And there are the mentioned issues with the developer experience of the people who would have to use those tools, the time that has to be invested, and the risk if it goes wrong.
Ofcourse Github (remote) is interesting if you have multiple developers who need to touch the same assets. Just like the Team Foundation Server (Team). But we haven't had problems with that... Nonetheless: if this were a business we'd be obliged to have have either Git or TFS. But we aren't. Fortunately we don't have nearly the same code / file base as a business either.
Sky-castles,
If we had the means and the time it'd be a great idea to setup something professional with Octopus and powershell scripting. With a local repository on the server, which we can update from the remote repository. We'd need to write a program to stage an update and merge the necessary files remotely, transfer to the server, and finally copy-paste. Shut-down sequence, start-up sequence. And to work around the arcane things the stock updater does (there are arcane things the startup sequence does too). But given the age of NWN2 that's just a sky-castle... At least for the time being.
-
NegInfinity
- Posts: 2449
- Joined: Wed Feb 05, 2014 11:24 am
Re: Put the server code under version control
You put master code under version control, and get ability to revert code to the state in which it was at any point in time. Quickly. You can also transfer stuff between master/local module, because git is decentralized.Rasael wrote: So what does Git add? Maintaining a local code repository duplicates the master module on
You can quickly implement change in script, test them out, and then if it "doesn't work", you can store them into different repository branch, and revert to tested version, without data loss.
You can maintain several code versions in parallel, without data loss, sync between them (scripts for testing server, and scripts for master server, in the same repo), see differences at a glance, and transfer them over to master server without merging.
When something breaks, you'll be able to see what changed at a glance. Down to line number/specific word/letter that was changed since the last version that used to work. you'll also know who made this change, when and maybe even why.
When you discover long-standing bug, you'll be able to track down specific modification that introduced it.
I'm not gonna lie that binary haks are not the best thing to store in the git repo, but...
But if even SCRIPTS aren't under version control, it is pretty much equivalent to trying to fix electric socket with bare hands, while standing in puddle of water, in wet clothes with power still on.
You NEED to look into it. At the bonus side you'll also get an option for people to submit fixes and test stuff locally without breaking your code. At the very least you'll want 2das and non-compiled script files under version control.
It is not a "slight improvement" I'm talking about. It is absolutely vital tool that is absolutely necessary in any programming project that has more than 5 lines of code and existed for more than a day. Working without that is equivalent to having a death wish.
Here's an example for you:
https://github.com/ALandFarAway/ALFA-Base-Resources