I have edits and a commit I want to undo.
SmartGit offers "revert" and it also offers "revert & commit". What is the difference?
Do either of these modify source code or are they strictly changes within Git itself.
Both Revert and Revert & Commit will modify your source code in the working tree. Revert & Commit will -- in addition -- also immediately commit these modifications. With Revert you have to manually Commit yourself. The advantage of Revert is that you can tweak your commit, if necessary. Also, Revert & Commit may be unable to actually perform the commit due to conflicts.
Related
Can I use rollback in a specific database table in Oracle?
I unintentionally changed one of the fields of an entire table and have already been queried in other tables. Is there anything I can do to fix this?
Most probably not (the way you described it). Rollback will revert changes you've made during this transaction, i.e. since the last COMMIT (or ROLLBACK). If you set a savepoint (which you did not), you could have rolled back since that point.
I'm not sure what you meant by saying "and have already been queried in other tables" - does it mean that values you modified have been used to modify other tables? If so, rollback will still revert those changes as well, unless they have been committed. Otherwise, see whether Flashback helps, as it allows you to undo the past.
Or, as a final resort, restore everything from backup. It'll indeed annul everything you (or anyone else) has done, which might not be the best option.
if you didn't commit the command, i.e. you didn't explicitally used "COMMIT", then you can rollback even if you have been queried other tables.
I'm a single user looking into Bazaar Explorer gui. Consider this scenario:
Create repository.
Create FileOne and add.
Commit as rev 1.
Make changes to FileOne.
Commit as rev 2.
Create and add FileTwo.
Commit as rev 3.
Now, let's say that FileOne has problems and I want to revert to rev 1. If I do this FileTwo will be deleted. If I want to keep FileTwo I guess I can copy it somewhere outside of version control, revert to rev 1, and then add FileTwo back to version control. This seems clumsy to me. Is there a better way of doing this? Thanks..
You can do one of the following:
First, selectively revert FileOne, e.g.:
bzr revert -r 1 FileOne
bzr commit
This will restore FileOne to the way it was in revision 1.
Second, use reverse cherrypicking:
bzr merge -r 2..1
bzr commit
This will create a patch that inverts the change of going from revision 1 -> 2.
Either option will create a new commit, but with the changes made in revision 2 undone.
I have some code which I have already committed in say branch X. How do I commit the same code in Branch Y ? Is there any way to commit same code in multiple branches at the same time?
You can add the same commit using cherry-pick on you new branch.
Doc:
http://git-scm.com/docs/git-cherry-pick
Explained:
http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html
I want to migrate my database from v1.0 to v1.1 and one of the changes is updates on some of the values in Table1. I know that for INSERT, I can easily include a rollback command of deleting the values I just added, but how about a table alteration? Is there a way to store the current value and use this information for the rollback process (in the future)?
Thanks.
You can specify a <rollback> block (docs) in your changeset to describe how to roll back the change. Within your rollback tag you can use raw SQL or a <createTable> tag to re-describe what the table looked like before it was altered.
You can also specify the changeSetId and changeSetAuthor in the rollback tag to point to an existing changeSet that will recreate the table. This approach can be easier if there has been no other changes since the object was created but doesn't work as well if there has been multiple changeSets that modified the object since it was first created.
Any DDL operation (ALTER TABLE being one of them) in SQL Server is transactional.
It means that you can open a transaction, do alterations to the database objects, and rollback the transaction as if it never happened.
There are some exceptions, mainly actions involving filesystem operations (adding a file to database and such).
Is this possible without restoring whole database?
I have made changes which I would like to undo, but without putting DB offline, and doing full restore.
No, SQL Server does not have Ctrl + Z.
You protect yourself from this scenario by wrapping all DML statements in a transaction. So you have query windows with this:
BEGIN TRANSACTION;
UDPATE ...
-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;
When you run the update, verify that you updated the right number of rows, the right rows, the right way, etc. And then highlight either the commit or the rollback, depending on whether you performed the update correctly.
On the flip side, be careful with this, as it can mess you up the other way - begin a transaction, forget to commit or rollback, then go out for lunch, leave for the day, go on vacation, etc.
Unfortunately that will only help you going forward. In your current scenario, your easiest path is going to be to restore a copy of the database, and harvest the data from that copy (you don't need to completely over-write the current database to restore the data affected by this update).
The short answer is: No.
However, you don't have to take the DB offline to do a partial restore on a table or tables.
You can restore a backup to a separate database and then use TSQL queries to restore the rows that were negatively impacted by your update. This can take place while the main database is online.
More info on restoring a database to a new location:
http://technet.microsoft.com/en-us/library/ms186390.aspx
For future reference, as per my comment,
It is a good practice to use a TRANSACTION.
-- Execute a transaction statement before doing an update.
BEGIN TRANSACTION
... < your update code >
Then if the update is wrong or produces undesired results, you can ROLLBACK the TRANSACTION
-- Ooops I screwed up! Let's rollback!
--ROLLBACK TRANSACTION -- I have this commented out and then just select the command when needed. This helps to not accidentally rollback if you just press CTRL+E, (or F5 in SSMS 2012)
... and it goes away :)
When all is well you just COMMIT the TRANSACTION.
-- COMMIT TRANSACTION -- commented out, see above
Or else you lock the database for all users!
So don't forget to commit!
Yes, besides doing a full restore, there is a viable solution provided by 3rd party tool, which reads information from a database transaction log, parse it, and then creates an undo T-SQL script in order to rollback user actions
Check out the How to recover SQL Server data from accidental updates without backups online article for more information. The article is focused on the UPDATE operation, but with appropriate settings and filters, you can rollback any other database change that's recorded within the transaction log
Disclaimer: I work as a Product Support Engineer at ApexSQL
It is not possible unless you version your data appropriately or do a restore.
Possible but It will require lot of efforts.
SQL Server maintains logs for DELETED/UPDATED/INSERTED data in non-readable format and to read them you should have the efficient tool Event Log Analyzer.
As a slightly modified version to the answers above, I sometimes like to use an automatically rolled back transaction in combination with the OUTPUT keyword and the INSERTED internal table to see what will actually update as a result set.
For instance,
BEGIN TRANSACTION;
UPDATE TableA
SET TableA.Column1 = #SomeValue
OUTPUT INSERTED.*
WHERE <condition>
ROLLBACK TRANSACTION;
If the result set looks good to me, then I'll change the last statement to COMMIT TRANSACTION;.