I do use Netbeans and TortoiseHG to manage and view Mercurial changesets but my problem is that I want to see differences for a range of changeset.
Real case: Gil is working on a feature in his own repo and he adds more changes incrementally.
His changesets are: 47(message: initial tests), 48, 49 (message: fixed bug added in 47), 50 (message: feature ready).
[Changeset 46 was made by me (Alex) so I know the code until 46 inclusive]
If I do review each commit I might spend time on bugs he already fixed down the road (ex: I see a bug in 47 but he fixed it in 49).
I want to avoid reviewing each commit and I want to be able to review whole 47-50 range at once - as a single change set.
Is there any tool, option, tweak to achieve that?
TortoiseHg can launch a visual diff of two revisions or it can output a diff file for them.
The instructions for Windows are as follows:
Click on one revision
Ctrl-click the other revision
Right click on either of them
Visual Diff... will launch your configured visual difference tool and Export Diff... will create a patch file for you to review.
This is probably available for other OSs that TortoiseHg supports but the clicks may be different.
This launches KDiff3 on my system which gives a tree containing all the changed files. Double-clicking on one of the files show the changes in another pane.
Related
I am using mercurial via tortoiseHg (windows) as a source control management tool.
I am used to merge using beyond a compare. Today, I have to perform a very complex merge and I just discovered a new feature (my client was updated some days ago) that is extremely annoying.
When I have a conflit and ask Mercurial to take the "other" file and keep the original in a .orig file, the .orig is added with <<<<<<< local and >>>>>>> other, but more than this, the other part is merged into the original one !!!
The two parts are then unaligned and it's impossible to guarantee that the merge is OK because you have to review it line by line with no help from the comparision tool. (see screen below).
http://s13.postimg.org/yor6gno47/Untitled.jpg
I want to disable this feature, but so far, I am unable to do it. Thanks so much for help as this is furthermore blocking my work.
Regards.
The launching of a specific merge tool isn't something Mercurial controls. It does, however, have a robust mechanism for Merge Tool Configuration that allows you to provide a preference order and it will use the first one it can find. The builders of various Mercurial installation packages (ubuntu, etc.) and tools that include Mercurial (TortoiseHG, etc.) all provide their own Merge tool configuration preference list.
Either the old merge tool configuration list you had not longer points to Beyond Compare at the right location (upgraded BC and the directory name changed, etc.) or you got a new merge tool configuration list when you updated some software that included mercurial. Either way that page on MergeToolConfiguration will help you find your preference list in your hgrc files and update or correct it.
Tl;Dr: this isn't a "new" feature it's your new installation being less tailored for your system than your old one. Maybe find who packaged that one and copy the merge tool config.
We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).
ClearCase client version: 7.1.1
ClearCase server version: 7.0.1.2
We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.
This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.
We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:
File.txt is checked out by 2 team members.
Each members makes a change in the file (in other regions of the file).
First developer checks in the code to ClearCase, no problems here.
Second developer checks in, gets a merge popup notification.
When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.
Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.
Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?
Edit: Illustrating the problem with images of the issue:
The file Manager.cs is at version 27.
Two developers are checking it out.
One made a change, checked in.
The other checks in, gets the merge notification.
This is what i see in the graphical merge:
Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !
Why is this happening automatically??
Image can also be seen here: Image
Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).
If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.
Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.
For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.
Since my initial answer 4 days ago, 2 new information came about:
ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
That is never good to have a client with a version more recent than the server.
We have performed the same test, without using the "Graphic merge". This option worked as expected!
That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).
I have installed the MercurialEclipse plugin. I am finding it very hard to use.
I have been using the Mercurial support in NetBeans for a while now, there are many things I would like to be able to do in Eclipse if possible:
In NetBeans any changes to source code are highlighted in the line
number area. New code is green, modified code is blue, and removed
code is red.
Files in the project explorer appear as blue or green for modified
and new respectively.
In NetBeans I can right click any directory in the project explorer
and go to Mercurial->diff to get a visual diff for all files (in the
directory I clicked) that have changed since the last commit.
When I right click a directory in Eclipse I am given a compare with but
with only 1 option (each other) that is disabled.
Even worse, when I
right click an actual file I know has changed and go to compare with I am
given 3 options (local history, parent changeset, different
changeset). If I click parent changeset it does not give me a diff. I assume this is beacause its the first time the file has changed since 3 commits ago. Which doesn't make since, I just want to see what I have changed to review it before commiting. I would like this to show me the changes I have made since my last commit i.e. the changes I will be committing.
Please note I am not trying to bash on Eclipse and I am not trying to Praise NetBeans. I am just wanting to know if there is a way to setup a workflow in Eclipse like I am used to in NetBeans.
Some of the things you are requesting are not specific to the VCS you are using, they are part of the Eclipse Team support, so they will work with any VCS system.
1) Showing the code changes: The closest Eclipse has to that is Team -> Show Annotations, but I don't think this will show the added/changed/deleted lines from the current version. I would file an enhancement request to Eclipse about this.
2) Eclipse shows different icons for added and changed files. You should see a blue + for an added file and a brown * for a changed file.
3) To easily get a diff from what's committed, you can do Team -> Synchronize. This brings up the Synchronize View. Another way is you can do a Team -> Commit at any level and then in the listing of the files, double-click the file which will bring up the comparison between the files (that will show one file at a time). Another thing you can do is select Compare -> Another Revision... and select the desired revision in the dialog (this will show all enclosed files in a single compare editor). Finally, the Compare -> Parent Changeset on a specific file does shows the changes from the committed parent for me, even if it was not changed in the most recent revision. It's possible you have encountered a bug in Mercurial Eclipse.
Be sure you are using the latest version of Eclispe and also Mercurial Eclipse. Mercurial Eclipse is pretty active and they are adding and fixing things all the time. I tested this on Eclipse 3.7.1 with Mercurial Ecipse 1.9.1.
This is an older question, but i had the same problem, and found this info useful.
I'm transitioning from netbeans to eclipse. I'm no expert but:
For text highligting you can use the "quick diff"
a. Windows -> preferences -> General -> editors -> quickdiff
b. enabling quick diff with mercurial quickdiff seems to mimic netbeans mostly.
For diff's of a changeset of files. I think you need to use the Team Syncroniztion perspective as is mentioned before. Its actually pretty slick once you get used to it.
I'm trying to migrate to TFS from VSS and I need to be able to show what files were checked in between two releases. In VSS we would just label the code for a release and view history between labels and generate a report to show the checkins and the comments. Is there a way to get similar results with TFS? Or show the differences between two changesets or labels?
The command line tool tf.exe gives you more options than the GUI (and can either give results in a Dialogue or as standard output --- good for feeding into further processing).
E.g.
tf hist . -r /version:C10~C1000
will list all the changesets affecting this folder and content recursively between changesets 10 and 1000.
See the documentation on MSDN.
If you need maximum flexibility, you can create your own commands using the TFS client assemblies. Unfortunately documentation is somewhat sparse.
Right click on your desired folder on TFS (e.g. the root folder), you'll find following two options:
1, Apply Label - this allows you to apply label to a particular version of that folder.
2, Compare - this allows you to compare that folder between versions, and one of the choices is comparing by label.
Right click on any node in TFS Source Control and choose 'View History'
This will show you all changesets ordered by date descending.
Double click on those and you can see the detail about the change set: the comment, associated work items, and files that were changed.
As Jeff said, right-click on the project, any folder or file, and choose "View History" to see all changes. If you know when your labels were applied, it's easy to scroll down this list until you hit a particular date/time.
For an exact list between two labels or changeses, use "tf.exe history" (as Richard says) from a Visual Studio command prompt (in your start menu in the Visual Studio 2005 folder). For more info on this just execute "tf.exe help history".
For day to day changes, if you use TFS build you can see the changes since the last build at the bottom of the build information page (Double click the build name in Team Explorer, then double click the specific build. Scroll to the bottom of this page and open "associated changesets". I've set out CI build to not associate changesets, which means that our daily test build lists all changesets since the previous daily build - a great summary of the changes for our testers to get their teeth into.
I was using the command line tf hist and getting the changesets to compare by finding the highest changeset in a label or branch changeset, but having a manual process and using the command line didn't go over too well here. I used Carl Daniel's code to write a little web application that will bind the changes to a datagrid.
If you're looking for something special the standard interface doesn't give you it's fairly simple to write your own application that links into TFS. I'd definitely suggest it.
I'm pretty used to how to do CVS merges in Eclipse, and I'm otherwise happy with the way that both Subclipse and Subversive work with the SVN repository, but I'm not quite sure how to do merges properly.
When I do a merge, it seems to want to stick the merged files in a seperate directory in my project rather than overwriting the old files that are to be replaced in the merge, as I am used to in CVS.
The question is not particular to either Subclipse or Subversive.
Thanks for the help!
Merging an entire branch into trunk
Inspect the Branch project history to determine the version from which the branch was taken
by default Eclipse Team "History" only shows the past 25 revisions so you will have to click the button in that view labeled "Show All"
when you say "Show All" it will take you back past the branch date and show you all the history for trunk as well so you'll have to search for your comment where you branched
NOTE: if you use Tortise SVN for this same task (navigate to the branch and select "Show Log") it will show you only the branch history so you can tell exactly where the branch began
So now I know that 82517 was the first version ID of the branch history. So all versions of the branch past 82517 have changes that I want to merge into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "All"
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Re-Merging more branch changes into trunk
Insepct the trunk project history to determine the last time you merged into trunk (you should have commented this)
for the sake of argument let's say this version was 82517
So now I know that any version greater than 82517 in the branch needs to be merged into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "Revisions" radio button and click "Browse"
this will open up a list of the latest 25 branch revisions
select all the revisions with a number greater than 82517
press OK (you should see the revision list in the input field beside the radio button)
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Resolving Conflicts
You should be at the "Team Synchronizing" perspective. This will look like any regular synchronization for commit purposes where you see files that are new and files that have conflicts.
For every file where you see a conflict choose "right click - Edit Conflicts" (do not double click the file, it will bring up the commit diff version tool, this is VERY different)
if you see stuff like "<<<<<<< .working" or ">>>>>>> .merge-right.r84513" then you are in the wrong editing mode
once you have resolved all the conflicts in that file, tell the file to "mark as merged"
once all the files are free of conflicts you can then synchronize your Eclipse project and commit the files to SVN
I typically check out both branches and then use the compare to each other option which does a synchronize-like compare of the two source trees. After integrating the changes into one branch, you can recommit back to the repository.
Use Eclipse integration, it works perfectly fine.
The main change from CVS, is that you only merge deltas from a branch, ie changes from one revision to another.
That is to say you have to track the correct start revision somehow (unless you have svn 1.5 merge history)
If you got that right, it's only up to you to get the changes right with the compare editor.
Firstly, if you are seeing ">>>>>" and such in your files when you view them in Eclipse, this probably means that you are not looking at the file with the proper compare editor. Try right-clicking on the file in the Project view or Synchronize view and selecting "Edit Conflicts" to bring up a compare editor that will show you the conflicting regions graphically rather than as text. Note that the compare editor that comes up for "Edit Conflicts" is different from the one that you get when you just doubleclick on a file in the Synchronize view -- the doublieclick compare editor shows the differences between your current file and the way it existed when you last checked it out or updated it, while the Edit Conflicts compare dialog shows the differences between two sources of changes (for instance, the changes you merged versus the changes that existed in your workspace before you merged).
Secondly, you may wish to be aware of a bug in some versions of the Eclipse subversive plugin which causes all files that accepted merge changes to be incorrectly marked as having conflicts. This bug has been fixed, but a lot of people don't seem to have updated to get the fix yet. Further details here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=312585
Remember that with svn reverting a modified tree to a clean state is fairly easy. Simply have a clean workspace on the merge destination branch and run the merge command to import the modifications from the merge source branch, then synchronize your workspace and you will get your usual eclipse comparison window showing all the merge modified files and the conflicts.
If for some reason you can't solve the conflicts you can svn revert on the project and go back to a clean state, otherwise you do the merge in place and once you are done you can commit. Note that you don't have to commit, once you are done handling the conflicts you can also return to the dev view, verify that the code compiles, run your unit tests, whatever and then synchronize again and commit (once the conflict are locally resolved they won't come back)
last time I looked, when you use subclipse merge command it will overwrite the merged file (using conflict markers to show conflicting areas) and put the original left and right side of the merge in the same place. it shouldn't put anything in different directories.
As a rule of thumb, it is best to commit all merge modifications in a single commit and to only have the merge modifications in the commit so that you can rollback the merge later if needed.
openCollabNet's merge tool for subclipse is pretty neat. There are many merging types available and the merging I just performed with it when seamlessly. I recommend it.
The one thing that syncrhonize view in eclipse lacks is check-in capability. In Team synchronization view I can view all my changes and resolve conflicts, so it would be rather intuitive to check-in right there instead of going back to java view and do check-in.
I would advise not trying to use Eclipse's plugins as your primary access to Subversion.
If you are developing on Windows, TortoiseSVN is the best program that I have seen for Subversion access. Explore to the directory of which you wish to merge, right click on it and use the Tortoise SVN merge option. Assuming a non-interactive merge, once you get conflicts, you'll have to go through each conflicted file and edit the conflicts before marking them as resolved. For this process I recommend a program called KDiff3, which shows your local repository copy (what was stored in the .svn before the merge), your local copy (including any changes), and the copy coming from the repository, and allows you to easily see (and even hand-modify if needed) the result of the merging. It also handles a bunch of minor conflicts automatically.
KDiff3 is portable, TortoiseSVN is a windows shell extension, so if you're using another environment, I would try to just use SVN to merge. But that would be much more of a pain :)
I landed here because I was looking for a way to merge in an external merge editor (KDIFF3) but start the merge from eclipse. I wasn't satisfied with the answers provided above. So here is ho to configure kdiff3 as merge and diff editor for SVN in eclipse:
go to Windows -> Preferences → Team -> SVN -> Diff Viewer
Add a new config (add button):
Extension or mimetype: * - if you wish you can specify different mimetypes for different editors, I didn't need that thus the alquantor.
Diff:
Program path C:\Program Files\KDiff3\kdiff3.exe (or wherever you have your merge editor - sry for the windows path, feel free to add a linux version in the comments or edit this answer.)
Arguments:
${base} ${mine} ${theirs}
Merge:
Program path C:\Program Files\KDiff3\kdiff3.exe
Arguments:
${base} ${mine} ${theirs} -o ${merged}
This will probably work as well for other merge editors, but with a different argument syntax (figure it out an let us know :) ).
The usage is as usual (team->edit conflicts) for merging and compare->foo for the diff view.
Cheers