I decided to do a big coding overhaul in one of my Rails apps where it was easier to start again from scratch and then re-add the pieces from my old code one by one until I had most of it reintegrated. Now I want to basically take what I have now and make it my new app and get rid of the old one, but I want to old git log from that app to be present, and my app changeover to be treated like just another commit (albeit a big one). Any good way to do this?
I thought of deleting the entire directory structure of the old app except for the .git directory and then copying in the whole directory structure of the new app, adding, and committing, but that seems rather messy. Is there a better way to do it?
I thought of deleting the entire directory structure of the old app except for the .git directory and then copying in the whole directory structure of the new app, adding, and committing, but that seems rather messy. Is there a better way to do it?
That sounds perfect. You'll want a git add -u in there as well to catch any deletions.
Related
I am using Pug for SSR in my application, but even after I make some changes to the pug views, Express does not seem to keep track of them. Can someone help me out, because worse still, the bug made its way to production and I some stuck with old changes. Even when I delete the endpoint in my code, it still shows up the same old code. I also tried deleting the project and start over again, but nothing changed. Even when i delete the view file, it is like the endpoint still exists
After two long months of my tolerance being put to the test, I was finally able to find the solution to this. At first I thought Pug was the issue, then I tried Mustache for my template engine(check it out BTW, it's also cool) but the problem didn't seem to go anywhere.
The real issue is this: For some reason I had this file in my public directory called index.html and maybe when you use this line app.use(express.static("public")) express looks for that file and it seems to override the rest of the res.render() functions for the home route. However much I kept deleting the routes, it seemed to persist and that file kept on being served.
But after removing the index.html file from the root of the public directory, everything now works normal.
Hello helpful persons,
I'm working with trying to set up some new branch structures in our companies codebase for organization and sanity purposes. True to form decision makers have changed their minds and want the structure to be changed a bit from what I already have in place. Not an over-the-top request though, because no one is yet using the new structure so I have "free reign".
I need to simply move these thousands of files in the containing branch directories (//depot/main/... and //depot/dev/... respectively) into a //depot/main/[product_name]/... structure etc. which I'm on board with and understand the advantages.
While opening the files from //depot/main/... for edit and move I see in my output that there are several warning messages:
warning: edit of deleted file
and
warning: move of deleted file
How can I tell perforce that I do not want to open deleted files for edit, and in turn that I do not want to move deleted files to the new location(s)?
I have a feeling that there is some documentation that I am either not understanding or not finding properly.
Generally you only get that particular warning if you aren't synced to head and are trying to move a file. Make sure you are synced to the head revisions.
As suggested by raven you should probably be using integrate for this. Generally my recommendation is to use 'p4edit/p4 move' intra-branch and 'p4 populate/integ/copy/merge' for interbranch branch integrations.
sometimes when working in rails, I work on several things at once using git branches
sometimes, I'd like to test new ideas by implementing them and testing how and if they work accordingly. This involves sometimes adding models and migrations.
When switching branches, however, the migrations were already migrated to the DB and they stay, causing problems later on..
Is there a way to work with several branches and each to have different migration files, and before starting to work on a branch to "soft reset" the db only to the current migration files without losing data?
Normally, in development, I need some sample data that I keep in seed.rb which enables me to recreate the db, its structure and the sample data with a rake task.
Another thing I did was to keep more than one database. I would then just manually change the entry in database.yml according to the current git branch.
I have the following scenario:
I'm starting development of a long project (around 6 months) and I need to have some information on the database in order to test my features. The problem is that right now, I don't have the forms to insert this information (I will in the future) but I need the information loaded on the DB, what's the best way to handle this? Specially considering that once the app is complete, I won't need this process anymore.
As an example, lets say I have tasks that need to be categorized. I've begun working on the tasks, but I need to have some categories loaded on my db already.
I'm working with Rails 3.1 btw.
Thanks in advance!
Edit
About seeds:I've been told that seeds are not the way to go if your data may vary a bit, since you'd have to delete all information and reinsert it again. Say.. I want to change or add categories, then I'd have to edit the seeds.rb file, do my modifications and then delete and reload all data...., is there another way? Or are seeds the defenitely best way to solve this problem?
So it sounds like you'll possibly be adding, changing, or deleting data along the way that will be intermingled amongst other data. So seeds.rb is out. What you need to use are migrations. That way you can search for and identify the data you want to change through a sequential process, which migrations are exactly designed for. Otherwise I think your best bet is to change the data manually through the rails console.
EDIT: A good example would be as follows.
You're using Capistrano to handle your deployment. You want to add a new Category, Toys, to your system. In a migration file then you would add Category.create(:name => "Toys") or something similar in your migration function (I forget what they call it now in Rails 3.1, I know there's only a single method though), run rake db:migrate locally, test your changes, commit them, then if it's acceptable deploy it using cap:deploy and that will run the new migration against your production database, insert the new category, and make it available for use in the deployed application.
That example aside, it really depends on your workflow. If you think that adding new data via migrations won't hose your application, then go for it. I will say that DHH (David Heinemeier Hansson) is not a fan of it, as he uses it strictly for changing the structure of the database over time. If you didn't know DHH is the creator of Rails.
EDIT 2:
A thought I just had, which would let you skip the notion of using migrations if you weren't comfortable with it. You could 100% rely on your db/seeds.rb file. When you think of "seeds.rb" you think of creating information, but this doesn't necessarily have to be the case. Rather than just blindly creating data, you can check to see if the pertinent data already exists, and if it does then modify and save it, but if it doesn't exist then just create a new record plain and simple.
db/seeds.rb
toys = Category.find_by_name("Toys")
if toys then
toys.name = "More Toys"
toys.save
else
Category.create(:name => "More Toys")
end
Run rake db:seeds and that code will run. You just need to consistently update the seeds.rb file every time you change your data, so that 1) it's searching for the right data value and 2) it's updating the correct attributes.
In the end there's no right or wrong way to do this, it's just whatever works for you and your workflow.
The place to load development data is db/seeds.rb. Since you can write arbitrary Ruby code there, you can even load your dev data from external files, for instance.
there is a file called db/seeds.rb
you can instantiate records using it
user1=User.create(:email=>"user#test.com",
:first_name=>"user",
:last_name=>"name",
:bio=>"User bio...",
:website=>"http://www.website.com",
:occupation=>"WebDeveloper",
:password=>"changeme",
:password_confirmation=>"changeme",
:avatar => File.open(File.join(Rails.root, '/app/assets/images/profiles/image.png'))
)
user2=User.create(:email=>"user2#test.com",
:first_name=>"user2",
:last_name=>"name2",
:bio=>"User2 bio...",
:website=>"http://www.website.com",
:occupation=>"WebDeveloper",
:password=>"changeme",
:password_confirmation=>"changeme",
:avatar => File.open(File.join(Rails.root, '/app/assets/images/profiles/image.png'))
)
Just run rake db:seed from command line to get it into the db
I'm using Paperclip (2.3) to handle image uploads on a Rails 3.0.3 app running on Ubuntu. Paperclip is handling the uploads as advertised BUT the RackMultipart* files that are created in the application's /tmp folder persist -- that is, they simply accumulate rather than deleting themselves. I realize that I could use tmpreaper to delete old tmpfiles but I'd really like to find a more elegant (and scalable) solution.
I had a previous issue with temp files (i.e. RackMultipart* files) accumulating in the Rails app's root directory (instead of in /tmp). I resolved this by explicitly setting the temp path in my environment.rb file like so:
ENV['TMPDIR'] = Rails.root.join('tmp')
Is there another environment variable that needs to be set to make sure that the tempfiles are handled properly -- i.e. deleted once they've been saved in the model? I'm not sure if this is a problem with Paperclip or my Rails setup.
I've searched high and low but have made little progress on this. I'd be grateful for any leads.
Sincere thanks.
PS - I'm using currently using S3 for storage. This doesn't seem to be tied to the problem though -- I had the same problem when I was storing the files locally.
The TempFileReaper is the Rack middleware thought to handle this issue.
http://www.rubydoc.info/github/rack/rack/Rack/TempfileReaper
Including this line in the application.rb solves the problem:
config.middleware.use Rack::TempfileReaper
I don't know if this is anymore elegant but this is what I am doing after the file is saved"
tempfile = params[:file].tempfile.path
if File::exists?(tempfile)
File::delete(tempfile)
end
UPDATE: Problem should be resolved in rack-1.6.0.beta2. I see it's already being used in Rails 4.2.0.rc2.
Below workaround served me well for almost a year:
I've added this at the end of controller action that accepts file uploads:
Thread.new { GC.start }
This triggers Garbage Collection of unused Rack::Request objects which also deletes associated temp files. Note it doesn't sweep temp file of current request, but it does remove previous files, and prevents them from accumulating.