I'm using Eclipse 3.4 (on Mac) and I've got an annoyance with the text comparison having the files I'm comparing in a specific order which is not what I want.
When I compare two files it always seems to put the first file (alphabetically) on the left, and the latter one on the right, but I want to be able to change this on a comparison by comparison basis.
IE comparing 'file-a' and 'file-b' will always have 'file-a' on the left, but that isn't always what I want. I seem to recall in earlier versions of Eclipse that changing the file that was right-clicked when choosing Compare With -> Each Other changed the order, but that isn't working for me in 3.4.
An example of why I care:
I've just performed a subversion merge and had a conflict, so I now have the following files:
file
file.merge-left
file.merge-right
file.working
I've made changes to file and now want to compare file to file.merge-right and file.working to file.merge-left and split the editors so I can have the working/left changes sitting above the file/right changes, and then just page through the compare editors and make sure the differences between this file and the file that the merge comes from have been preserved, but file is on the left while file.working is on the right, and hence the differences need to be compared diagonally rather than just comparing top and bottom.
Yes, that's actually very annoying. We use an external tool called Beyond Compare (we have a corporate licence) which can swap the two sides easily.
What you should probably do is raise an enhancement request on the relevant Eclipse team with Bugzilla. If there's enough demand, it'll either make it into the next release or someone will write a new (or modify the existing) plug-in to allow swaps.
There's a "Swap From and To" button when the Compare screen comes up. Using Eclipse 3.6. I'm actually looking for a way to change default behavior. For example, when I compare revisions, it always have the latest revision on the left side instead of right unless I click the swap button before comparing.
As I mentioned here, Eclipse Neon.2 (4.6.2) has a button to swap the views:
Related
Is there any way to compare two identical projects (with some differences) in vscode? I want to find the difference in the files (e.g. main.c in the first project vs main.c in the second project and so on recersively)
Note: The are a lot of files. I don't want to compare them one by one (by right-clicking on them and choose the compare with option)
I am unaware of VS Code doing this. Beyond Compare does this very well. (exactly what you are describing)
You can choose two directories. The UI will show two columns, and in each they will be highlighted red if there are discrepancies. You can open each folder to see what the differences are.
Don't ask why, but I'm using VS2003 and need to see what changes have taken place in all the files in my project between a certain date and now. I see how I can do that, namely by right-clicking on each file and selecting "Compare Versions" then selecting By Date and the date for the version to compare with the latest. This is good; what would be (much) better is if I could generate a report whereby it would show me something like:
The line "*Sit on a potato pan Otis*" was removed from BachBestsMozart.cs.
The line "*Any enterprise requiring new duds is likely a dud itself*" was added to CheapSunglasses.cs
(etc.)
...but hopefully ignore unimportant differences, such as formatting, comments, etc.
Does such a possibility exist, or am I doomed to open each file, one by one?
UPDATE
I ended up having to compare them all, one by one, eyeballing them. At least it's better than VS2010 is acting for me right now:
Awedly (I am awed, but not in a good way), the "Compare" functionality in VS2010 doesn't hold a candle to that in VS2003!
In VS2003, I can select a Target Version based on a date to compare with the current version - so, if I pick 2/13/2013, I may end up comparing files dated recently (today or whenever the file was last modified) and one modified on 2/13/2013, or 2/1/2013, or whenever the last modification prior to the date I selected took place.
In VS2010, it looks like I should be able to do that, but the combo box for the comparison file is grayed out/inacessible! Heavens to Murgatroid!!!
Or maybe this is just related to the problem I'm having where I can't update anything in the Package Manager - even trying to update Nuget gives me a can't load library err msg; and the package console is "read only" for me, too... I wish there were a "repair" functionality built into VS that would check up on missing or corrupt DLLs and replace them...
I need some help. I have to view difference between two folders, but I need to ignore the file version number (project version number) which is in the header of the file. Like that:
#version Release: $Revision: 9939 $
And do you know the best diff merge software for doing that in Mac OSX and the most beautiful. I know diff merge and Kaleidoscope. I love Kaleidoscope but, it cannot make some difference between two folders.
Many thanks before.
Try going into DiffMerge → Preferences → File Windows → Rulesets. You can modify the existing ruleset for your file type (or add a new one if no ruleset exists already).
Edit the ruleset you're interested in, and go to Lines to Omit. In there you can add a regex to match that line #version.
What I'm having trouble with is getting the folder diff to honor this. I find that files with no diffs according to my rules still end up in the folder diff as a non-match, but when I open the file diff window it says Files are identical or equivalent under the current RuleSet. Not sure if this is a bug or I still have something configured wrong. If I go into Folder Windows → Equivalence Mode and dig into the help there, I think I have all the folder diff properties set correctly to honor my rulesets, but still no luck.
It's a pity you need MacOS. For Win32 there is WinMerge readily configurable via Tools/Filters/Linefilters where you simply enter a regular expression to be ignored.
http://manual.winmerge.org/Filters.html
For example, you might use line filters to ignore comments or certain type of generated code, like version control system timestamps
WinMerge 3 will be Qt based hence MacOS positive too, but current 2.x is not yet.
I am doing a refactoring of my C++ project containing many source files.
The current refactoring step includes joining two files (say, x.cpp and y.cpp) into a bigger one (say, xy.cpp) with some code being thrown out, and some more code added to it.
I would like to tell my version control system (Perforce, in my case) that the resulting file is based on two previous files, so in future, when i look at the revision history of xy.cpp, i also see all the changes ever done to x.cpp and y.cpp.
Perforce supports renaming files, so if y.cpp didn't exist i would know exactly what to do. Perforce also supports merging, so if i had 2 different versions of xy.cpp it could create one version from it. From this, i figure out that joining two different files is possible (not sure about it); however, i searched through some documentation on Perforce and other source control systems and didn't find anything useful.
Is what i am trying to do possible at all?
Does it have a conventional name (searching the documentation on "merging" or "joining" was unsuccessful)?
You could try integrating with baseless merges (-i on the command line). If I understand the documentation correctly (and I've never used it myself), this will force the integration of two files. You would then need to resolve the integration however you choose, resulting in something close to the file you are envisioning.
After doing this, I assume the Perforce history would show the integration from the unrelated file in it's integration history, allowing you to track back to that file when desired.
I don't think it can be done in a classic VCS.
Those versioning systems come in two flavors (slide 50+ of Getting git by Scott Chacon):
delta-based history: you take one file, and record its delta. In this case, the unit being the file, you cannot associate its history with another file.
DAG-based history: you take one content and record its patches. In this case, the file itself can vary (it can be renamed/moved at will), and it can be the result of two other contents (so it is close of what you want)... but still within the history of one file (the contents coming from different branches of its DAG).
The easy part would be this:
p4 edit x.cpp y.cpp
p4 move x.cpp xy.cpp
p4 move y.cpp xy.cpp
Then the tricky part becomes resolving the move of y.cpp and doing your refactoring. But this will tell Perforce that the files are combined.
Does RCS have something like svn/p4 delete where it keeps the file history but marks it as deleted? Or do I just remove the file and the matching v file in the RCS directory? What's the recommended way of removing and/or moving files with RCS?
RCS has nothing like 'svn delete'; it does not manage directories.
You do not want to remove the RCS file (RCS/filename,v); you need it for access to past work and historical versions. You simply no longer get (co) it from RCS.
You asked about moving files. There are (at least) two options.
One is to move the underlying filename,v file from one name to the other - possibly in a different directory. That loses the previous information - you would not be able to regenerate a previous release because of the renaming.
The other is to copy the underlying filename,v to newname,v; this preserves the history by leaving the original file in place, and gives the new name of the file a history too.
I generally use option 2, but I'm anal retentive about regenerating old versions of the software.
This technique becomes more difficult if you want to create a new file with the name of the old one. I'd then use the old file and start a new main version (e.g. jump from version 3.15 to 4.1) with the new material. If you decide your new material must have version 1.x numbers, you've hosed yourself - you have to choose between backwards compatibility and forward motion. I'm not so attached to specific version numbers as all that (but would recommend against using 'the year' as a part of the version number; I have a number of files with version 2003.2, etc, and when I edit those, I have to remember to change the version to 2009.1, etc.).