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.
Related
Here is the context:
I am using egit within Eclipse
I made a number of commits that I have not pushed to the remote repository
I suddenly notice a bug with my app that wasn't there before
How can I quickly update my working directory with earlier git commits until I find the first commit that introduced the bug? How do I then get back to my latest local commit?
I used hard git resets to do this recently and would have lost my last set of git commits if I hadn't found this answer so there must be another, safer way to achieve the same result.
I am running into a bug in my latest version of the code and want to go back in time until the bug no longer shows up.
That is called git bisect, and is not implemented in Egit.
You should consider using git in command-line, in order to launch a bisect session.
I just figured out the answer to my own question.
It's actually quite simple:
Do git checkout of earlier versions until identifying the last version that does not exhibit the bug and the first one that does
Then do a git switch to the master version to go back to the latest committed version
The checkouts are not intended to make further changes to the code but are quick and useful for updating the working directory without messing with the git directory, which is all what's needed to quickly pin-point the appearance of a new bug in the git tree.
I've just discovered, a surprising for me behavior of cvs.
I change file1 localy
During this time people change other unrelated parts of the same file, and commit to the repository
I update my local copy from repository
At this point I expect my local copy of file1 to contain all changes made by others to this file, unless the update above reported a conflict. However, when I do now diff with head, I discover lot's of differences coming from changes made by others in parts of the file that I did not touch at all.
Any ideas? Is this just the limited abilities of cvs to merge? Any wrong setting? Something in my workflow?
CVS has very limited merge facilities. Switch to a modern system such as Git (perhaps via git-cvsimport if the repo maintainer is uncooperative) if you want a better merge experience. See also Best practices for using git with CVS
The final solution is :
1. Save your local code to another place manually
2. Revert the files which may has conflict to the HEAD (most latest) version on CVS server.
3. Add back your change to the Reverted file.
The concept for above solution is to CLEAR UP all the possible issue by REVERT and get a 100% clean version from repository then add back our changes.
It can resolve below issues which caused by code out of date / code base messed up.
CVS commit had a conflict and has not been modified
CVS update failed
CVS not sync
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.
I'm using Eclipse Indigo SR2 with the (built-in) EGit plugin v.1.3.0.201202151440-r and haven't been able to find any way to easily review all my changes before making a commit.
I used Eclipse with SVN for years, and this was always very easy to do. I would typically right-click on my project, select Team->Synchronize, double-click on the first changed file (in the Team Sync perspective), then hit Ctrl-. repeatedly to review all changes in one file, and then proceed to the next file, as I wrote a summary of my changes for the commit message.
But of course, git is very different from Subversion, and so my workflow must change. With EGit, "Team Sync" only appears to be useful for reviewing changes between my local files and the remote repository (i.e. before a push to the remote). I need a way to review changes since my last commit to my local repository. I generally don't even care to (re)review changes before a push to remote (and if I did, I'd prefer a simple equivalent of git log to see what commits I'm about to push).
If I right-click on my project and select Team->Commit, I am presented with a window that does almost everything I need to do (select files to stage, commit, write a commit message, amend a previous commit, etc.). What it doesn't allow me to do is quickly and easily review all my changes in a compare editor. I can't believe this capability doesn't exist! It seems I am required to double-click on each individual file, review the changes, close the compare editor, and double-click on the next file. That's ridiculous!
TL/DR - I am looking for a simple GUI equivalent (in Eclipse) to do what I am easily able to do from the command line using git vimdiff (where vimdiff is a git alias that uses vimdiff as the "difftool" to cycle through all modified files) followed by git commit (with perhaps a git add or two in between).
If no one has a good solution, I am curious about how others handle their commit workflow with EGit. I've been getting along fine committing from the command line (not that Eclipse is happy about that) but I can't believe that EGit is as near-useless as it seems to me. Perhaps my google-fu is not as strong as it once was?
Says here that you can see the diffs between the working tree and any given reference. Perhaps you should try out the latest version (Juno) of Eclipse/EGit and see if it's gotten any better?
Update: I've tried this out in the latest Eclipse, and as far as I can see it works fine. Here's how:
In the moment of writing this, Eclipse Juno 4.2 is the version you should go for. On the download page, you can pick between several packages according to your needs. The 'Eclipse IDE for Java Developers' comes bundled with EGit, but you can also install EGit into any distribution using the Eclipse Marketplace (under the Help menu).
Once you've imported your project into Eclipse, make sure the project is "shared":
Right-click project -> Team -> Share Project.. -> Git
Now do the following:
Switch to the Team Synchronizing Perspective.
Click the little synchronize button in the Synchronize View.
Choose Git
Pick a suitable branch to sync against, like refs/remotes/origin/master
Make sure to check the "Include local uncommitted changes in comparison" box
Click Finish
Now, change some files and watch them appear in the Synchronize View. Double-click the changed files to see the diff (like in the screenshot below).
Are you aware of the 'Git Staging' view. It keeps track of all the files that have changed and you can review the changes any time. (This can be a bit better than using the commit dialog)
An alternative is to commit all changes without reviewing, and then use the history view to compare two commits (Simply select the last top most commits, right click and select 'Compare with each other'). This way you do not have to keep double clicking individual files. If you need to change something you can always 'Amend' the last commit. (I usually follow this approach)
I am writing this as of Eclipse Oxygen, but it should apply to other versions as well.
Option 1 with team synchronizing view: right click the project > Compare with > Commit. You can choose your latest commit here, even if you haven't pushed it to repository.
Option 2 with diff view: If you want to see the "diff" version without committing, you can achieve this by right clicking your project > team > stashes > Stash Changes > check Include untracked files. This will save all of your changes to a stash. Then you will right click project > team > stashes > select stash you saved. You click the green arrow at the top right to re-apply all of your changes you stashed back to your code. In the same stash window, you will see a "Diff" tab at the bottom right. Clicking on the diff tab will show your changes in the red/green highlighted diff style. I wish there was a way to generate a diff view without stashing, but this is the only work-around I have found.
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.