How do I visually diff two revisions of files in TortoiseHg 2.0.3? - diff

In TortoiseHg 1.7, I could point Hg Repository Explorer at file and see a list of versions. Selecting 2 versions and right-clicking allowed me to launch my favorite Visual Diff tool to display their differences.
I recently upgraded to TortoiseHg 2.0.3 and can't find a way to visually diff anything except the working file with the tip version. "Revision History" shows a list similar to the old Repo Explorer, but doesn't seem to have a way to lanch a visual diff. Has this featured been removed?

As noted by #dls, you can get a visual diff of any two revisions of the repo by:
Clicking on the first revision
Holding CTRL and and left-clicking on the second revision
Right-click on either revision
From the context menu, select Visual diff...
This method works with your user-defined external diff program (default is kdiff3)
TortoiseHg v2.0.x also includes a feature to diff arbitrary versions of a single file.
Open the manifest window
Right-click on the file
Select Compare file revisions
This opens the Hg file log viewer as shown below:
From this window, you can diff arbitrary versions of the file. Select the before revision in the upper-left. Select the after revision in the upper-right. The bottom half of the window shows a visual diff.

A co-worker found the answer on bitbucket. This feature was not implemented in TortoiseHg 2. It will probably be added to the next release in July. See: https://bitbucket.org/tortoisehg/thg/issue/260/visual-diff-button-in-hg-log-viewer

I'm pretty sure you can do this diff in TortoiseHg v2.0.3 - try selecting one revision by clicking and then CTRL-clicking on another revision and selecting "Visual Diff...".
I can't test this right now because I have to use v1.1.7 for unrelated reasons, but during my time working with v2.0.X I was able to do this. The bitbucket link you included looks like it's for a button to perform the visual diff, not the underlying feature.
NOTE: I was able to get a co-worker to test this, it does work (at least in some fashion) in TortoiseHg v2.0.3

Related

How to find the SVN branch(s) or commits that resulted in the modification of certain parts of the code

Sometimes, I need to know when certain changes were committed to the SVN branch or trunk. For example, I see a code block and I want to find the approximate date when it was added, and what is the commit info used. Usually, the context of certain changes are described on the commit level, and the developer doesn't add comments to describe why it was added.
I am using Eclipse 2019-09 and SVN plugin.
Tarek
Display of Changes (Using Tortoise SVN and KDiff3)
To view the changes, follow the steps below:
Right click on Tortoise SVN icon and select "Show Monitor".
Screenshot 1: Display of Tortoise SVN Project Monitor
To connect to the remote repository, SlikSVN registration information is entered.
Screenshot 2: Connect to remote repository
Use the GUI for commit notifications, file history and more.
Screenshot 3: Display of changes
For example, to view the contents of the files in the sixth revision, double click on the file name and the KDiff3 windows opens.
Screenshots 4: By double clicking the file, the KDiff3 windows opens
Changes made using the KDiff3 windows are displayed at the file content level.
Screenshots 5: Display of file content level changes
In addition, differences between revisions (unformatted) and commit declarations can be viewed in history via the Eclipse IDE.
Screenshot 6: Viewing revisions via Eclipse IDE

How to checkout from diff view?

I am using Perforce 2015 client (P4V) on Windows 7.
I changed some files in my IDE. Then I use "Folder Diff" in Perforce to locate them. I was expecting to find "checkout" right click menu on the "Folder Diff" Perforce window in order to move my changes to a changeset but I don't see any "checkout" around.
How can I checkout directly from Diff view?
If you changed files on your workstation, but Perforce doesn't know about those changes yet, the command you're looking for is "reconcile".
I believe that P4V's Folder Diff may only show you the reconcile options if you use Folder Diff from the Advanced Reconcile Options variant of Reconcile Offline Work.
So to perform this style of Folder Diff within P4V, you should start by context-clicking on the root folder in your tree view and choosing "Reconcile Offline Work", then choose the Advanced Reconcile button at the bottom of that display, as described here: http://www.perforce.com/perforce/doc.current/manuals/p4v/Offline.html
Then, when Advanced Reconcile opens up the Folder Diff, you will see suggestions in red lettering about what your options are for each file (Mark For Edit, Get Revision, ec.). You can then pick one of those options by context-clicking that file in Folder Diff.
Alternatively (and perhaps more useful, once you get used to it), you can do this from the command line. If you haven't worked directly with the command line before, you can context-click "Open Command Window Here" on the root folder of your workspace treeview to get to the command window. Then, type
p4 status
to see a report about what changes you have made to your files, and
p4 reconcile
to make those files open for add, edit, or delete, as appropriate. Then close the command window and refresh P4V to see them.
I am not sure what your exact scenario and IDE is. I am using Visual Studio with the Perforce plugin, and when I make any changes in my source this plugin will check-out this file automatically (you can also choose to be prompted). So no need for folder diffs to locate any changes.
Should your IDE miss any integration plugin's then a very simple workflow could be like this:
Go to Perforce and check out all the files in your solution
Make your edits in your IDE (online or offline doesn't really matter)
In Perforce choose 'Revert Unchanged Files' on the changelist
And voila, only the changed files will be left in your changelist, you can then review the changes and submit to the depot.
NB: should in the mean time another developer have made any changes to any of your changed files, Perforce will warn you that you need to execute a Get Latest and then Resolve (i.e. merge) the changes.

Eclipse and EGit: How to easily review changes to ALL modified files before committing to *local* repository

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.

Netbeans + Mercurial Graphical Diff

New to Netbeans (6.9.1) and Mercurial (1.7.5) (our company doesn't believe in open source software), I am specifically trying to get NetBeans' "Show History" command to work. Viewing this website, NetBeans <3 Mercurial, this looks like it should be simple. Make at least two commits, go to "Team -> [Mercurial ->] Show History" and you should see side-by-side changes. However, in both side-by-side screens within my NetBeans, all it says is .
On the other hand, if I use the command-line, typing "hg diff -r 3:4 file.htm", for instance, I get a valid diff. "hg diff --rev 4 file.htm" also gives a valid diff against the local, non-committed, changes.
Within NetBeans, "Local History" works quite well, but when I right-click, Mercurial -> Diff, the "Base" file on the left shows nothing - I'm assuming this is the latest committed file - while the local version on the right shows up.
My question: Is NetBeans set up correctly to work with Mercurial (it seems to be correct in all other cases), is Mercurial itself incorrectly set up (this seems like a hard thing to mess up), or is this a case of user-error?
I just started using NetBeans as well. One gotcha I noticed, when you do Mercurial operations, it only shows you results based on your selection in your project tree.
Try selecting the root "Source Files" in your project tree and then see if there is a difference when you run the command.

Rolling back bad changes with svn in Eclipse

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.