I have a large repository (20000+ commits) that takes a while to do a one-time cutover from SVN to git. There is a tangled web of hundreds of branches, some of which are proper branches, others are more like developer sandboxes, some are partial branches, some are tags, some are unrelated repos which I will be extricating, etc. so I am familiar with the subgit configure feature and modified the config file in the subgit directory.
These branches create a lot of errors from subgit (I don't know why for most of them), and while I don't care about individual branches/errors, I don't want to exclude them all. There was an explosion of creating these branches around the 10000th commit, so I have to wade through the first half of the repo before any of these errors come up (about 4 hours).
So I'm wondering: Is there a way to restart the import after an error with a modified config file? It could either comb back through the commits it already did and make sure they look good or start at the problematic one, either way it would ideally succeed because I changed the branch mapping to exclude the problem. Thanks!
It is possible to restart the initial import with the same command used for the initial start, but the thing is that the mapping configuration change that affects branches mapping (means adds or removes branches to/from the configuration) requires the repository import restart from scratch as such the configuration changes usually affect the resulting Git objects.
Related
My site is messed up and I am trying to fix it, and regardless of it I get help, it is going to take awhile likely, and it's really important that my site be live, even if it's a crappy version with just the articles and no template.
Would it not work to make a backup of the database, install Joomla fresh (the same version) and connect it to that duplicate database (then point my domain there) and then go back to working on fixing the current site that is live now? Are there any issues I should know about going in? There's a good chance the issues are related to the template or extensions (at least my understanding so far, see my other post for details on the issue) so I would think it would be faster to do this to get a working site rather than trying to turn off and on each extension, especially when I have to do it manually (and I don't know how yet) as I can't access the backend.
If this will work, do I choose the database when I install or just install empty and then change what database it connects to or do i install empty and import the tables (and how)? Still have to figure out if I can make a clone of the database and not all the files as it takes hours.
Thanks for the help, and if I should have appended this to the other post I apologize, but I figured its a separate issue.
First, ensure you have backups of both the files and the database. Then make a local copy of your site where you will work later.
The infection may lie:
in the Joomla core files, with extra content (which is usually fairly easy to spot, for example an eval of a large base64-encoded variable);
in extra files (keep in mind that even images could contain malicious code), these would be usually triggered outside of Joomla for spamming or other nefarious purposes
in the database content.
Fix:
Apply a fresh Joomla update package over your site; you will only fix n.1 above. This may restore some functionality for the first hour of survival.
Analyse the logs, and try to figure out how they got in. You need to step up security as obviously what you have is not enough.
Install a fresh Joomla, add all extensions that your site uses, copy the images folder, then connect it to a copy of the compromised database. This will fix n.1 and 2 above (as you got rid of any extra files). This may survive until they figure out you fixed it; but if you haven't patched your security, they will hack into your site again. Keep a copy of this, and restore as needed as you proceed with the following step.
Export the db to sql format (mysqldump or phpmyadmin may come in handy), then search for any xss traces, php code, javascripts that may have been injected. Since a complete control could take days, and assuming the malicious code links elsewhere, look for strings such as "https://" and "http://"; escape / as \/ and \\\/ to account for json-encoded data as well.
Once the db is clean, your local copy is reasonably safe; update all extensions and Joomla, and use it to restore the website until you fix your security.
It might work, i mean cloning the DB as far as joomla version is the same. It won't break like that, but may fail if files for extensions are not found. This is somewhat wrong, the question is how many extensions you are using and how much cleansing you need.
On the other side you mention that the site should be 'live'. Just do everything on localhost, test, fix templates, etc. Then if you're sure you're done, use akeeba backup and deploy new version to your server without long delays.
Any kind of cleansing needs some start.
You can clean the site while live, depends on complexity.
Clean might be done offline and deployed.
Sometimes import/export custom routines are needed, so you have to make own tools for everything. It occurs with large data, like when people used to made mess inside images folder or something like that.
4 ...
It's pointless to make copies of DB. You install the same version of Joomla on your local server, then you install the same template, you copy styles etc.
Then you import data with your own tools or paid ones. Estimated time is from few hours to few days, it's just data :)
I'm still getting the hang of VS Code.
I want to make a react app using 2 different GET API URL endpoints but the exact same UI. In essence, I want to change just the base URLs between the 2.
I've tried creating a new branch in VS code to make 2 separate files but once I make edits in the master branch, the changes reflect in the new branch also.
Is there a way of making a different stand-alone branch from the VS code?
I've searched through the forums to no precise avail and I'm not that good at git. Thanks.
It is likely that your changes are being shown when you switch branch because you haven't commited your changes to a branch before switching.
Let's say you are on the master branch and make some changes. You can create a new branch new-feature and change your current working branch to new-feature bringing your existing changes across. This is useful because sometimes you will start to carry out some work before realising the scope is a bit too big and should be it's own branch.
If you want to keep the changes you have made on your current branch, you need to "stage" your changes with git add your_filename.here (or git remove). Once you have added and removed all changed files you want to keep on that branch, you need to git commit them. This is the step that finally adds the changes to the version history.
Now when you change to new-feature branch, your changes on master will not be there.
There are a number of GUI applications that make the git model more intuitive such as SourceTree, Github Desktop, and SmartGit
I have a file "db-connection.php" that has to be different for each version of my server. (Localhost, Dev and Production). At first I thought .gitignore was the answer, but after much pain and research, I realized that .gitignore only works on untracked file: e.g. files NOT already in the Repo.
For obvious reasons, the localhost version I'm using with xampp requires that the db file be within the repo. Of course, this means that every time I push it to Dev, it ruins the Dev db connection.
Is there a way to tell .git "Yes, I realize this file exists, but leave it alone anyway"?
This is a common problem, and there are two solutions, depending on your needs.
First, if you always are going to have the same configuration files and they will change depending only on the environment (but not the developer machine), then simply create the three versions of the file in your repository (e.g., in a config directory), and copy the appropriate one into place, either with a script or manually. You then remove the db-connection.php file and ignore it.
If this file actually needs to depend on the user's system (say, it contains personal developer credentials or system-specific paths), then you should ship a template file and copy it into place with a script (which may fill out the relevant details for the user). In this case, too, the db-connection.php would be ignored and removed from the repository.
There are two things people try to do that don't work. One of them is to try to keep multiple branches each with their own copy of the file. This doesn't work because Git doesn't really provide a way to not merge certain files between branches.
The other thing people try to do is just ignored the changes to a tracked file using some invocation of git update-index. That breaks in various cases because doing that isn't supported, and the Git FAQ entry and the git update-index manual page explain why.
You can use the skip worktree option with git-update-index when you don't want git to manage the changes to that file.
git update-index --skip-worktree db-connection.php
Reference: Skip worktree bit
Database team is implementing code changes, using Visual Studio SSDT database projects with Git source control. Everyone is pushing to main Release branch with code review (only 5 developers on the team). All the database coworkers are only allowed pushing to different files only (tables, sprocs, functions), etc. The way work is assigned, none of us push or work the same sql file. Eventually all good changes from Release (currently in Work) are merged into Master branch (Production Ready).
Code Review ---> Push to Release Branch (Currently in work during Sprint) ---> Merge to Master Production Ready Branch
(a) What are the negative consequences of utilizing this strategy in Git?
(b) For cleaner history, should everyone Rebase ReleasePublic Remote into ReleaseLocal, or conducting Pull? (Fetch/Merge), I would think Rebase is answer for cleaner history.
Note: I agree, it would be annoying only if we are working on the same file and pushing changes. Alternative Strategy to create different feature branches and then merge into main branch. We are refraining from this strategy since each developer has 10 dba admin related changes a day, creating many branches and merges is time consuming and cumbersome-
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
Devops
The bottom line is if it's working for you then it's working.
The purpose of the source control solution is to assist you in producing software.
Use this setup until it doesn't work and then adjust. (Please note that all 5 of the devs could start using feature branches, if they want/need, without interfering with the other team member's flow).
Having said that there are consequences of using a single branch. Here are two examples
Releasable main/release branch
One of them could be shown in a following scenario:
A release happens
A commit with a bug in file A is committed
A commit file B is committed
You want to release the changes made to file B\
Now you don't have a releasable snapshot of the repo
If the changes for file A were tested in a feature branch then master/release branch is in a releasable state more often.
Pull requests
Having feature branches allows to use Pull Requests (which is a layer on top of git) better - your code reviews may be get easier to enforce and track.
We currently use an SVN repository to ensure everyone's local environments are kept up-to-date. However, Drupal website development is somewhat trickier in that any custom code you write (for instance, PHP code written for a node body) is stored in the DB and the changes aren't recognized by the SVN working copy.
There are a couple of developers who are presently working on the same area of a Drupal site, but we're uncertain about how to best merge our local Drupal database changes together. Committing patches of database dumps seem clumsy at best and is most likely inefficient and error-prone for this purpose.
Any suggestions about how to approach this issue is appreciated!
Unfortunately, database deployment/update is one of Drupals weak spots. See this question & answers as well as this one for some suggestions on how to deal with it.
As for CCK, you could find some hints here.
As for php code in content, I agree with googletorp in that you should avoid doing this. However, if for some reason you absolutely have to do it, you could try to reduce the code to a simple function call. Thus you'd have the function itself in a module (and this would be tracked via SVN). But then you are only a little step from removing the need for the inline code anyways ...
If you are putting php code into your database then you are doing it wrong. Some stuff are inside the database like views and cck fields plus some settings. But if you put php code inside the node body you are creating a big code maintenance problem. You should really use the API and hooks instead. Create modules instead of ugly hacks with eval etc.
All that has been said above is true and good advice.. To answer your practical question, there are a number of recent modules that you could use to transport the changes done by the various developers.
The "Features" modules is a cure the the described issue of Drupal often providing nice features, albeit storing lots of configs and structure in the DB. This module enables you to capture a feature and output it as a pseudo-module (qualifies as a module with .info and code-files and all). Here is how it works:
Select functionality/feature to export
The module analyses the modules, files, DB content that is required to rebuild that feature elsewhere
The module creates a pseudo-module that contains the instructions in #3 and outputs everything (even SQL to rebuild the stuff in the DB) into a module package (as well as sets dependencies for other modules required)
Install the pseudo-module on your new site and enable it
The pseudo-module replicates the feature you exported rebuilding DB data and all
And you can tell your boss you did it all manually with razor focus to avoid even 1 error ;)
I hope this helps - http://drupal.org/project/features
By committing patches of database dumps, do you mean taking an entire extract of the db and committing it after each change?
How about a master copy of the database? Extract all tables, views, sps, etc... into individual files, put them into svn and do your merge edits on the individual objects?