I need a way to figure out which files are left over after upgrading Moodle to a newer version.
I have:
Old version + many plugins
New version
Merged version
In the new version some files have been removed but they still exist in the merged version.
I could start with the new version and copy all the plugins but many are in different sub folders which will take too long.
Is there a quick way to list or delete these left over files?
I would create a clone of Moodle in a separate folder.
git clone git://git.moodle.org/moodle.git moodleclone
Then check the version of Moodle in /version.php in your code - look for $release = '2.x.x. Then checkout the exact version of the Moodle clone
cd moodleclone
git checkout v2.x.x
Then use Meld to compare the 2 folders. http://meldmerge.org/
meld ../moodleclone ../yourmoodleversion
This will then show any code differences between the 2. You can see if its an official Moodle plugin or one that has been added.
It would be better if you use the uninstall plugin option via site admin -> plugins because it should remove any data in your database too. You might also want to do a clean install in a new database using the Moodle clone, then dump and compare the database structure from the clone and your code to see if there are any database changes.
Related
We are developing a project built with yeoman angular generator. Now appears the need of "puppetize" it for deployment.
Obviusly the machine serving client part should be provided with a compiled (minimified, optimized) version of the angular project. But I have no idea if we should store it on our bitbucket repo -for example on the master branch when tagging a new release-
I couldn't find any post about this practice and I could use some help.
There are some facts about angular minified version:
It is uglificated and minificated, so code is unreadable and hard to change.
It demands compilation with tool like gruntjs, which takes some time to build each time.
It works on server, but when you choose to deploy non minificated, revisioned version, you can have other problems during adding new versions to same repo - scripts have same name and are cached in browser and possible other problems.
You decided to deploy compiled version to a client machine.
If you are using version control like git. you can add to repo a folder with compiled version, so your repository have sources and dist in same folder. Possibly you have also backend code, sometimes in backend code you can add compiled version to host on server. It's better to have all code and builds in one repo, so you can do this with one command.
In my case, i wrote scripts in java, to copy builded folder to another folder. We use also Visual Studio for backend, so i wrote script adding new filenames to .cs file, so it can be visible by continous integration tool.
Going to a final, create new branch in git from release master branch. It is useful to have copy of your partial work.
I don't know how often you have releases, but you can solve it by having branches in git.
So your branches can look like this:
master
release1
release2
...
Assuming you are doing development on master and copying new versions to releases.
In previous versions of Capistrano, there used to be a task/ command via which i could easily deploy just one file from my local to the server, I didn't need to do the steps like first commit the changes, then push it to git repo and then deploy the whole repo.
With latest version 3 I can't find the similar command.
I was searching for the same feature that existed in Capistrano 2.
Reiknistofa made a gem. You should have a look to https://github.com/Reiknistofa/capistrano-upload
I installed SQLite into my WPF project via Nuget. Then added the entire project to a remote repo. Then I cloned the project on another machine, and had a broken build.
x64\SQLite.Interop.dll was missing.
I'm puzzled why Git didn't include one file from my project. I checked the repo on BitBucket and confirmed it is not there. Git status reports nothing to commit, working directory clean
It added the x86 version, but not the x64 version, I can't imagine why.
(project)\x64\SQLite.Interop.dll Git ignored this file!
(project)\x86\SQLite.Interop.dll
You might want to check the .gitignore file at the root of the repo. If it contains for example x64, it would ignore this file.
There would be two main possibilities then:
edit this file to fit your need
or force this file to be added; ie: git add -f x64/SQLite.Interop.dll
However, committing binary files is often frowned upon. It's true in particular if you want to keep up to date with the latest package, hence if you plan to commit new versions of the dlls on a regular basis.
You might rather want to consider Nuget package restore feature. Basically the idea is that you commit a config file, and the client will automatically download the corresponding packages.
I have old app. It based on CakePHP 2.0.5.
I want to upgrade it to current latest version, 2.2.5.
Is it enough to replace new lib folder with the old one? or application folder needs to be changed, too.
(checking changelogs for about 17 versions takes time a lot!!!)
I think I should read Cookbook:
first:
http://book.cakephp.org/2.0/en/appendices/2-1-migration-guide.html
then:
http://book.cakephp.org/2.0/en/appendices/2-2-migration-guide.html
I have a drupal installation running on OpenShift. I have been installing all modules and themes using git (commandline). However, I attempted to install the modules directly and the installation worked.
The problem that I now face is that when I attempt a pull request all I get is the modules and themes I had installed using the commandine and not the ones that I installed 'directly'.
Any one with a heads up on this?
OpenShift runs your code form a checkout of the git repository located at ~/app-root/repo within your gear. When you upload files using Drupal (instead of the git repository), the modules and themes are installed in this checked out directory and are not tracked in git.
I you are using a scaled application, I would recommend that copy the modules/themes and check them into git instead of the Drupal install method.
For now, to retrieve all your files you can try the rhc export command.
Thanks to #kraman above I got a hint of what to do.
I ran rhc snapshot save -a appname and got all the files. At least I know where to start off from since I can access the files.
A word of caution though for drupal users on openshift, just use git or sftp for pushing files and save yourself the headache.