I was just updating my webapp on AppEngine but it got stuck while compiling. I pressed CTRL-C to abort, and appcfg.py gave me some output that it would rollback the update. Since this had happened multiple times today and I knew that there was an update, I downloaded the newest Python SDK, deleted the old one and tried to update again. Now it keeps telling me that there is still a transaction going on by myself, but whenever I try to rollback using ~/google_appengine/appcfg.py update rollback [my-app-directory] it says that the Directory does not contain an rollback.yaml file. I am absolutely sure I did not delete any file in that directory.
Is there any way to solve this without having to use a new ID?
rollback is a command like update. You need to rollback the previous update before launching a new update:
appcfg.py rollback [my-app-directory]
then
appcfg.py update [my-app-directory]
I found out what to do myself. I set the version in the app.yaml file to 2 and was then able to update it. Next thing I did was to go to appengine.google.com, chose "Versions" on the left and selected the new one as default.
Related
I'm having a lot of problems running my solr server. When I have problems committing my csv files (its a 500 MB csv) it throws up some error and I am never able to fix it. Which is why I try to clean up entire indexing using
http://10.96.94.98:8983/solr/gettingstarted/update?stream.body=<delete><query>*:*</query></delete>&commit=true
But sometimes it just doesnt delete. In which casese, I use the
bin/solr stop -all
And then try, but again it gives me some errors for updating. Then I dedicided to extract the install tarball deleteing all my revious solr files. And successfully it works!
I was wondering if there is a shorter way to go about it. I'm sure the index files arn't the only that are generated. Is there any revert to fresh installion option?
If you are calling the update command against the right collection and you are doing commit, you should see the content deleted/reset. If that is not happening, I would check that the server/collection you are querying is actually the same one you are executing your delete command against (here gettingstarted). If that does not work, you may have found a bug. But it is unlikely.
If you really want to delete the collection, you can unload it in the Admin UI's Core page and then delete from the disk. To see where the collection is, look at the core's Overview page on the right hand side. You will see Instance variable with path to your core's directory. It could be for example: .../solr-6.1.0/example/techproducts/solr/techproducts So, deleting that directory after unloading the core will get rid of everything there.
Is there a git hook that runs when I hit the "Commit" button in SourceTree?
What I am trying to do is add everything. I've tried the following, in the file ./git/hooks/pre-commit:
#!/bin/sh
git add .
echo "hook added everything!"
It runs all right, but the timing is wrong -- it appears to run as a part of actually performing the commit. So what happens is that git first decides that that nothing has been added, so the commit needs to fail. THEN it runs the hook and adds everything. Lastly, the commit fails. If I repeat the commit, it will succeed the second time. But that's wrong on several levels. What I really want is to add everything before it opens up the window for the commit message. Then if I want to un-add some stuff, I should be able to do that in that window. Lastly, when I tell SourceTree to go ahead with the commit, I don't actually want a hook at that point, as I've already configured add/remove the way I want it to be.
The problem is, you cannot commit in SourceTree unless you have added something by staging it for commit.
You're trying to start the commit process in SourceTree before having staged anything - you simply cannot do that.
I have an application that is now 4+ years old that is exhibiting some odd behavior on our latest deployment. The application uses nHibernate for all inserts / updates / selects, etc. We are currently using .NET 2.0, and nHibernate 1.2 (I know, we need to upgrade)
This deployment is on Windows 2008 Server x64, IIS 7.5 - what I have seen so far is that the application runs, but is unable to insert or update records in the DB - reads seem fine so far, but writes are a problem. SOME writes actually work, inserts into some small tables, but most never even make it to the DB.
Using SQL Profiler, the insert / updates never make it to the server, and turning log4net up to DEBUG, and show_sql true - the select statements appear, but the insert / update statements never make it into the log at all, and never show up at the server.
What's even more odd is that the application seems to be oblivious to this - the commandandclose runs without exception (open session in view with an httpmodule), the domain objects come back with uuid's generated, etc. but never get persisted.
Certainly an upgrade is due, but I would hate to try it during a deployment, and without time to accurately test the app. Any ideas?
My guess is that the default ISession FlushMode has been changed from Auto to Never or Commit. Never means that the session will flush when Flush() is called by the application; Commit means that the session will flush when a transaction is committed.
Back out your current deployment and return to what you had before. Then look for the mistake someone made. If it used to insert and now does not, then something is wrong with your current code. If it isn't creating the insert/update statments, then I'd look first at where they are supposed to be created. Did the current deplyment actually insert record or update them in dev? Did anybody test that or were you relying onthe fact that it didn;t pop up an error? If it did work in dev and doesn't work in prod, I'd look at the envirnmental differnences between dev and prod.
Both good answers, the problem was in the deployment. The web.config was setup for IIS6, and the deployment to IIS7 did not properly setup the open session in view HttpModule that is used to commit the transaction. Changing the pipeline mode from Integrated to Classic solved the problem.
After a fresh checkout, I want to get ALL files,
specifically this file: etc/config.ini
However, once I modify etc/config.ini, I do not want it committed with "svn commit ..." nor should it be reverted on a "svn up".
This would allow you to get default values on an initial checkout (convention over configuration), but then after configuring, you don't want these "local" configuration files committed into svn.
The best way to do this is not to directly version control the file.
A common way to avoid this issue is to have config.ini.sample (or something along those lines) under version control, and then config.ini ignored in your svn:ignore property.
Then, after checking out, copy config.ini.sample to config.ini and you're good to go. This way you can also version control your template config file.
If you use TortoiseSVN and/or VisualSVN (>= 1.5), you can move these files to the changelist 'ignore-on-commit'. This causes the files to show up in a separate section in the commit dialog, and never automatically selected for committing.
Obviously this is a TortoiseSVN-specific solution.
Jason already hit on the general accepted solution (the one promoted by the SVN folks themselves), but there is another option, if you're using TortoiseSVN as the client. When you're at the commit dialog, right-click the file you don't want to ever commit and choose Add To Changelist->Ignore On Commit. It will still show up in the commit dialog every time you go to commit it, but it defaults to unchecked so it won't actually be committed unless you explicitly check the box. Again, only useful for Tortoise, so if you use the same WC with a non-Tortoise client, you'll accidentally commit it.
For example, a file is modified to do an enhance ticket, what I want to do is associated the committed file to the ticket. When using Trac and SVN together, how will I know that a file is committed to solve a certain ticket? Is this possible?
Thank you.
As stated on the TracWiki, the intended workflow is:
A Trac user begins work on a ticket
They obtain code from the version control system
After the work is completed they perform a commit of their
modifications to the version control
repository
The user inserts the Trac ticket number into the commit message as a
TracLink
Trac can now display the change set for the ticket
Where the TracLink is something like #1 or ticket:1 or even comment:1:ticket:2 when referring to a ticket.
If you miss creating the link when the commit is made, you can still create one in the ticket comments themselves using TracLinks such as: r2, r1:3, [1:3], log:#1:3, etc.
you can link to the revision when closing ticket: r253, e.g.
and you can link to the ticket in commit message: #7525, e.g.
other than that, I doubt that anything can be done.
Obviously you could parse log message with on-commit hook and make a notification of sorts re tickets of interest, but you'd need to have access to the server I guess.
You may find the Trac post-commit hook useful. It allows you to close tickets using your commit log messages. See the script here.