This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do I return to an older version of our code in Subversion?
I was looking at the diff in the commit window on Eclipse (with subclipse) and tried adding a line (by hitting enter) but instead committed by changes without a comment and without me making sure I wanted to commit the things I changed.
This added a commit with no comment and with changes I wasn't sure of to the remote repo. I checked out the previous revision and committed those changes over the commit I made accidentally.
So now HEAD is the same state as the revision before my accidental commit, but I would like to properly commit my changes now. I'm not sure how, though. When I switch to the accidental revision (to get my changes back), it doesn't let me commit because it says nothing was changed. I'm guessing it's comparing my local files to the revision I checked out, but I need it to compare it to HEAD.
What can I do here?
You could (svn) export your accidentally committed revision over your working copy. Then you can make your adjustments and commit your changes.
On the command line:
svn export -r <your accidental commit> <working copy directory>
In Eclipse:
right click on the accidental commit in the history view
select "Export..." and choose the directory containing your working copy
The easiest thing would be to make a unified diff of the revision you committed and then use the Apply Patch option to reapply it to your workspace.
You can also just do Show History on the changed file. Then find the revision, select the file in the appropriate pane, and choose the Get Contents option. This will make your working copy version of that file match the contents of that file in the selected revision.
In either case, your working copy should now show as dirty and you can review and commit when ready.
I ended up reverting the changes from the very last commit I made and then re-committing those after checking everything.
Related
I read few threads on backing out commits. Following are relevant
How to delete commits with egit?
What's the difference between Git Revert, Checkout and Reset?
But how do I revert/reset/restore back to clean original state. I just started working on new project and the original git directory structure got messed up after the first check in (because I incorrectly created git repository as eclipse project); this problem is discussed in "The short story" or "The longer story" of following link
http://wiki.eclipse.org/EGit/User_Guide#Creating_Repositories
Now I wanted to restore the original directory structure of git repo. In History window, I see all the previous commits and I can right click on them and back out to one of previous commits; sadly the history window doesnt show anything to prior first check in (or commit). But I want to back out to the original directory structure that existed prior to first commit (that way I will have clean repo without any code base in it). It doesnt matter if it is restore/reset/revert as long as git repo looks same as it was before first committ. Can I do this in eclipse/egit?
This isn't something that Git would have kept track of.
You might look into the Eclipse local history (which is separate from the history recorded by Git), but that is for a file only. Not a all structure.
It is best to recreate a Git repo, and make as a first commit your clean structure, before adding code base in it.
Go to git perspecive-> Expand the repo. Right click on working tree. Clean. Finish. See the below pasted image link.
clean in git perspective
I've used a number of version control systems over the years, and would say I've mastered SVN and Mercurial, but now I have a contract which requires me to use perforce. I have the basics under control, but occasionally I find an area where it's not clear exactly what perforce is doing.
Shelving changes is one of these.
This week I was in a situation where I was in the middle of a piece of work, and needed to change focus and work on a quick fix for someone. The old work was based on an older revision, and for the new piece of work I needed to be at the latest. So I...
Shelved my current changelist.
Updated my workspace to the latest revision
Did my work
Submitted it.
Unshelved my original changes
I knew I was at the latest revision when I unshelved, but "That's OK, I needed to update anyway". What surprised me was that I didn't need to resolve any files. Unsure about why that would be I...
Reverted my workspace
Updated to the revision I'd originally been working at
Unshelved my files again (I hadn't deleted the shelved version)
Updated to the latest revision
At this point perforce asked me to resolve files, and it wasn't a trivial resolve (i.e. not one that could have been done automatically).
This has left me with questions:
Is shelve just copying a file out of the way, and then copying it back? or is it storing a delta?
Is it possible to cause other's changes to be undone by using shelve?
How should I be working when this situation arises in the future?
p4 shelve saves your files on the Perforce server, but doesn't remove your pending changes from your current workspace. After issuing the p4 shelve command, you could have issued a p4 revert command to restore your workspace to the unmodified versions of your files, but from your description, it looks like you didn't do that.
So your update to the latest revision step (p4 sync) brought all the unopened files up to the head revision, but left your opened files as they were before you shelved them.
Your unshelve command had no real effect, since the files were already in the state you left them in before you shelved them.
As to your questions:
shelve is copying the files (probably as a delta, but it's not important to me as a user) to a place where you (or your coworkers) can get them later, but it's not "out of the way," since it doesn't automatically revert your shelved changes in your local workspace
shelving itself doesn't change the head revision of the file in Perforce; it's more like a micro branch. However, when you unshelve a file, you may have to integrate the changes you made before shelving the file with changes that have been made to the file since it was shelved. This can lead to others' changes being undone if you're not careful.
Strenuously.
Our Project is using CVS and its is integrated from eclipse and so we use Team Synchronizing to get the latest code from CVS but is there a way to revert the previous commit or update from repositry which we have done ?
I come from git background and so I am having hard time to find out this functionality from eclipse/cvs, any suggestion would be highly apprecaited.
It depends what you mean by "revert".
The git revert actually add a new commit canceling the changes introduced by the previous one.
With Eclipse, that would be (file by file): "Replace With -> History"
(see "How to properly roll back to an older version in CVS HEAD using Eclipse?")
And then make a new commit.
In other word, there don't seem to be any simple way to do this (when many files are impacted)...
Right click on the file -> Team -> Revert to Base. This will overwrite any local changes and revert to the most up-to-date version of the file in CVS.
Any this what you're after? (I have to admit that I find the question somewhat unclear)
If you mean it in the sense of uncommitting something you committed before, erasing it from the history of the file, then no, you cannot do that.
You can only get the previous version back from the repository and commit that again, making it clear in the comment that you reverted the file to a previous revision.
I am trying to merge my development branch back into the trunk of my repo. Steps I took:
Switch to trunk
check that it is up to date, resolve any conflicts
Go to Team->Merge
Select URL : development branch
Start Revision: Revision when branch was created
End Revision: HEAD
OK
This should do the magic - it opens up the syncronize view which is fine, shows me all the conflicts, but there the problem happens:
In the compare editor I see two files:
Local File | Remote File (306)
This is really strange, the revision number of the remote file is actually the one of the file in the working copy (trunk) and so is the content. The local file has the content of the file in the branch.
Now the arrow shows correctly that I am merging from left to right (branch to trunk). This also happens when I click ok.
BUT I can only move changes from right to left!!! That's not what I want - I do not want to overwrite the changes in the branches with the old content of the trunk. I want to move the content from left (branch) to right (trunk). But I can't even write in the right file.
I do not know why it writes remote file there?? It's clearly showing the working copy file in the remote file window, and the file from the branch (for merging) is shown in local file.
Some bug in Subversive?
Thx,
Martin
Merges are never been easy with subversive (as mentioned in this old SO question), so may be doing the merge externally (or with subclipse) would be easier here.
If your client and repository are both at least in SVN1.5, Subversive new merge capabilities are better, but still dangerous as illustrated by this thread.
Since Subversive has been modified for SVN 1.5 the whole merge behavior has changed. One thing I really liked is the ability to choose what changes I wanted, apply that to my working copy and then commit to trunk.
Subversive now no longer does that but forces all changes onto your working copy and then you choose what to put in the trunk.
This is not only undesirable behavior but it's also dangerous (if you ignore the possibility of a revert anyway). I prefer to commit things I know work. We have a release branch which gets changes which may or may not need to be migrated to the trunk.
Well this seemed mysterious at first, now I shall provide a decent stab at updating this answer for everyone. This regards merging using the SVN Subversive client for Eclipse:
You are doing your merge correctly, starting in Trunk and then pointing to your file under your local Branch. Your files open up in the "Text Compare" window under the Team Synchronizing tab. If you do not see conflicts over in the left hand navigation column, then your merge has just happened. Yes, this is confusing and non-intuitive.
What the Text Compare window offers you is the ability to undo your change (or any others that may have gotten into your merged file unawares) before you commit it. Remember that you are pulling in the file from Branch, so the idea is that the Branch file is in Trunk but in a kind of virtual limbo until finally committed, and changing or undoing unwanted changes here references the file in Branch (obviously). That is why you only have a one-way pipe (Trunk to Branch) to overwrite those changed merged into Trunk via your working copy. Your merge has taken place, but it's not quite official yet.
If all looks as it should, right click the file in the navigator window (left pane in my Eclipse Helios install) and choose Accept from the drop-down. Then click back over to your main code-viewing tab (in my installation it's PHP but it could be whatever you are using) and then commit the file to Trunk.
If you want to test this, do a view of the file "as is" in Trunk before committing and you should see your changes reflected there if you have done your merge correctly. This appears to be the way it is working for me on an OSX Snow Leopard Macbook Pro. Not sure if it's the same for Windows or Linux folks. I assume it's essentially the same/similar process.
it's easy
check out trunk with check out as... give a different project name.
Now you have both locally as working copy, trunk you wanna commit to and the branch you are working on and whose changes you have comitted to the repository.
Now rightclick the trunk project (and I mean the project, not single files) - merge - select the branch project (again, PROJECT)
accept all changes to local copy
commit what you need to trunk as used to
all fine, delete trunk again and keep working on the branch
especially with branches this seems super easy and worked like a charm for me
Let's say I have committed some bad changes to Subversion repository. Then I commit good changes, that I want to keep.
What would be easiest way to roll back those bad changes in Eclipse, and keep the good changes? Assuming that files relating to bad changes are not same as those relating to the good changes. How things change if good changes were made to same files as bad changes?
I am mostly looking a way to do this via Eclipse plugins (Subclipse or Subversive) but commandline commands are also interesting.
In Eclipse Ganymede (Subclipse)
Select project/file that contains bad change, and from pop-up menu choose:
Team -> Show History
Revisions related to that project/file will be shown in History tab.
Find revision where "bad changes" were committed and from pop-up menu choose:
Revert Changes from Revision X
This will merge changes in file(s) modified within bad revision, with revision prior to bad revision.
There are two scenarios from here:
If you committed no changes for that file (bad revision is last revision for that file), it will simply remove changes made in bad revision. Those changes are merged to your working copy so you have to commit them.
If you committed some changes for that file (bad revision is not last revision for that file), you will have to manually resolve conflict. Let say that you have file readme.txt with, and bad revision number is 33. Also, you've made another commit for that file in revision 34. After you choose Revert Changes from Revision 33 you will have following in your working copy:
readme.txt.merge-left.r33 - bad revision
readme.txt.merge-right.r32 - before bad revision
readme.txt.working - working copy version (same as in r34 if you don't have any uncommitted changes)
Original readme.txt will be marked conflicted, and will contain merged version (where changes from bad revision are removed) with some markers (<<<<<<< .working etc). If you just want to remove changes from bad revision and keep changes made after that, then all you have to do is remove markers. Otherwise, you can copy contents from one of 3 files mentioned above to original file. Whatever you choose, when you are done, mark conflict resolved by
Team - Mark Resolved
Temporary files will be removed and your file will be marked changed. As in 1, you have to commit changes.
Note that this does not remove revision from revision history in svn repository. You simply made new revision where changes from bad revision are removed.
You have two choices to do this.
The Quick and Dirty is selecting your files (using ctrl) in Project Explorer view, right-click them, choose Replace with... and then you choose the best option for you, from Latest from Repository, or some Branch version. After getting those files you modify them (with a space, or fix something, your call and commit them to create a newer revision.
A more clean way is choosing Merge at team menu and navigate through the wizard that will help you to recovery the old version in the actual revision.
Both commands have their command-line equivalents: svn revert and svn merge.
If you want to do 1 file at a time you can go to the History view for the file assuming you have an Eclipse SVN plugin installed. "Team->Show History"
In the History view, find the last good version of that file, right click and choose "Get Contents". This will replace your current version with that version's contents. Then you can commit the changes when you've fixed it all up.
In Eclipse using Subversive:
Right click your project > Team > Merge
In the merge window, select the revisions you want to revert as normally but also enable checkbox "Reversed merge".
Merge as normally.
I have written a couple of blog posts on this subject. One that is Subclipse centric: http://markphip.blogspot.com/2007/01/how-to-undo-commit-in-subversion.html and one that is command-line centric: http://blogs.collab.net/subversion/2007/07/second-chances/
The svnbook has a section on how Subversion allows you to revert the changes from a particular revision without affecting the changes that occured in subsequent revisions:
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo
I don't use Eclipse much, but in TortoiseSVN you can do this from the from the log dialogue; simply right-click on the revision you want to revert and select "Revert changes from this revision".
In the case that the files for which you want to revert "bad changes" had "good changes" in subsequent revisions, then the process is the same. The changes from the "bad" revision will be reverted leaving the changes from "good" revisions untouched, however you might get conflicts.
I have same problem but CleanUp eclipse option doesn't work for me.
1) install TortoiseSVN
2) Go to windows explorer and right click on your project directory
3 Choice CleanUp option (by checking break lock option)
It's works.
Hope this helps someone.