It finally started to annoy me enough to ask this question: how do I do a basic diff between two revisions of a file in CVS? Usually I want to compare the latest revision and some random old one. I'm using the Eclipse CVS plugin. When I use "compare with->Another branch or version..." from the selected file's (latest revision from HEAD or another branch) context menu, I get a list of branches, tags and dates but not revisions. Usually I have just created a date which I know is far enough in the past so I can compare the needed revisions but I thought that there must be a better way.
The answer is to show the file's history using context menu->Team->Show history, then choose two revisions and context menu for the selection->compare with each other.
There seems to be two main ways:
context menu->Team->Show history
which shows a linear history and you can select and compare between them, however it can be very bloated and hard to read when your project has lots of branches / tags. Personally i have found it less useful than:
context menu->Team->Show Commit history
Which seems to show the history of what has been committed to the specific branch/tag you are on. You can do it per file or per folder. The output is very similar but i find it clearer. You can click on a commit date and it will show you all the files (that you are interested in) that were committed on that date.
If you double click the file, it will then bring up another menu so that you can compare it with another file in the commit history
EDIT
(i find if you double click the "other" file, it doesn't do anything, you need to click "OK" in the dialogue, which seems silly to me. This might be effected by the fact I have the beyond compare 3 plug in, im not sure if it behaves the same without it)
EDIT
There is also a little button in the top right of the commit history window that allows you to switch to history view (but i always find it easy to read than the normal history view if i do it this way round)
Both should show you the comment added when committed and you should try and read about the differences between the but personally I haven't and its only form personal experience that i prefer commit history.
I apologize for not giving formal descriptions of each, this is purely from my personal experience of using them, i have not actually researched them both yet myself...
Related
We recently have moved from SVN to GIT, and until recently, the problems with the move were if not minimal, at least manageable.
Until a few weeks ago, we just had a single active 'master' branch, which was the old SVN trunk. But then, we added a branch to do a major upgrade while keeping the master available for bugfixes that could then be easily deployed.
The problem is that as soon as the different project team members started to check stuff in, the Eclipse (Mars 2 with EGit) Team Synchronization perspective started showing stuff as needing to check in that really didnt.
The first time I synchronized, a load of incoming changes came in (the blue arrow) which was unusual as I hadn't seen any since moving to GIT, - we just had to do a PULL instead - so foolishly I accepted them in. That ended up merging the changes we had put in the trunk with the branch, which we DIDN'T want to do.
Worse, even after pulling in those changes, they still appeared but now as conflicts, even though I accepted them and the files were identical. Nothing I can do (Mark as Merged, Overwrite, Commit...) gets rid of them.
Anyway, the most unhelpful problem is that now the Team Synchronization brings in hundreds (currently 825!) supposed changed files when I do a synchronize now. Many of these files are obscure ones that havent changed in years, and are clearly unchanged yet they show up. Trying to sift through the file list to find what I have actually changed is too much effort, especially as Eclipse helpfully refreshes the list with all the items I removed from the view each time I make any change!
So basically now I am resorting to GitKraken, which has substandard diff tools but at least shows an accurate view of what needs checking in. Why they decided on the Duplo-sized fonts that take up so much window space in the staging area I have no idea. And it's SLOW.
I now have a healthy dislike for GIT because its such a faff compared to SVN, although I acknowledge a lot of this is down to the GIT implementation in eclipse.
So, does anyone have any tips about how to get Eclipse to recognize that most of these files shouldn't actually be displayed? Am I missing some configuration somewhere? When I right click on the project in eclipse and do Team > Switch To, it correctly shows the branch Im working on, so why is it so inaccurate? Im using Eclipse Mars2 4.5.2 with JGit 4.6.1
Any tips appreciated.
For anyone else having similar problems with this, I sort of have an answer.
My answer is, that Im not sure what got it working, but my team synchronizing perspective now shows 99% the correct view. I clicked on various things with increasing desperation to get this to work and then some combination of the below in the Team Synchronizing perspective had the right effect:
In the Synchronize tab, select the down arrow next to the view type and select either Java Workspace (for the master) or Git Commits (for the branch)
Click the down arrow next to the Synchronize icon at the far left, select Synchronize and then Git, then select the correct destination (eg ref/heads/master) and then clic on 'Include local uncommitted changes in comparison'
Hopefully thats of help to someone.
I frequently have to diff two trees of source files, one coming from svn (in which you can only check out the whole tree) and the other my eclipse workspace.
99% of the time I only want to see diffs in files that are in both compare trees. The svn side has thousands of files my workspace does not, and I don't need to see them.
Is there a way to get the compare utility to only show files that exist on both sides, and skip the ones it would put the little minus icon on?
One option would be to carefully select only the files and folders you want included in the comparison, then right-click and choose Team > Synchronize with Repository.
That will open the Synchronize perspective and show a Inbound/Outbound view of changes. From there you can "pin" the synchronization and later come back to it and re-sync to see updated results.
You can read some more about the Synchronize view at http://www.eclipse.org/subversive/documentation/teamSupport/workspace_synch.php
I am using Mercurial, but I imagine that any merge tool that is aware of the version control system below it could do several things that a merge tool which is not aware of the version control system and only sees two "files" in two different folders, could never do.
I have been using KDIFF3, and recently tried BeyondCompare, and neither of them will do this, at least not that I could figure out.
What I want to do is best shown in this picture, an annotation column and perhaps even ability to open other windows from those annotation columns so I could browse specific versions of specific files to see context when trying to do a merge.
In the image here, I am showing a two way merge, but the same applies for a three way merge. To the right or to the left of the actual file content being shown, I would like a gutter or a right side annotation column showing some kind of annotation of where this change came from. Since Mercurial hex ids are relatively unfriendly and unhelpful, and since repository-local-revision-numbers are repository local, I think that a short text description based on commit comments would be most helpful. Of course, with Mercurial, 99% of these commit comments are going to say "Merge", and nothing else. (Groan.) But lets pretend for a minute that we weren't using tools and workflows that left us that crippled at merge time, and instead, that we could have a useful commit comment show up each time:
Right now the workflow for complex merges looks like this for me:
Using my distributed version control tool (mercurial), pull changes from another repository which is in effect a branch. Merge. The merge window for TortoiseHg is usually where I start all this from. This in turn lets me configure a merge tool (beyond compare or Kdiff3).
However, it does not appear that there is any merge tool (that I have seen) that can be told, "hey you're not just merging two way or three way with different versions of a file in the two completely different folders, with the names I told you, but those files are also files that have a complete edit history available to you to show your human the actual context, the commits that those line changes came from with their commit comments, often having a bug number as part of the commit which will give the person doing the merge the ability to see What in the Heck is Really Going on.
I would change from Mercurial to Git, for example, even, for a real merge experience that didn't force me to do manually what I think my tools could be doing for me automatically. I'm using Mercurial, TortoiseHG, and KDIFF3, and if I could just change from KDIFF3 to some other tool, or do ANYTHING at all to get annotations and merges together on one screen, I would like to do so.
I am comparing two folders using a diff tool. I have tried a few different diff tools, but right now I'm using WinMerge. There are many files which show as unique to the right or left side, for example:
On the right we have: /bar/some_organized_characters.txt
On the left we have: /foo/some_similar_organized_characters.txt
The text file may have slight variations, but it's mostly similar. I would expect a tool to exist in most merge/diff tools which could tell you that these files are likely the "same" (meaning they have the same base), but the file has been moved, renamed, and slightly modified.
What I'm specifically trying to do is a "vendor merge." We have some customized software, and we want to merge the changes from a recent official release with the changes we have made. Many files have moved in the latest official release, and finding every move/rename by hand is difficult.
use a version control tool to check for changes. Simply commit the structure as an initial commit. Then overwrite the structure with the new version and commit that. The patch view will show you moved items. I've been able to do this with Git very easily. These tools are made to see how something has changed and will dig into the contents of the file. In fact, in git, you can set the threshold of what percentage of changes in a file constitutes a move and change, vs a delete and create.
I don't think this is possible with diff (I couldn't find it in the manpage).
However git diff detects this by default and can create patches that are applied with git apply in a similar way to patch. You can use it on arbitrary directories, not just repos, with --no-index (see Diffing between two entire directories/projects in hg or git?).
I'm learning mercurial as my solo scm software. With other management software, you can put change comments into the file header through tags. With hg you comment the change set, and that doesn't get into the source. I'm more used to central control like VSS.
Why should I put the file history into the header of the source file? Should I let mercurial manage the history with my changeset comments?
Let the source control system handle it.
If you put change details in the header it will soon become unwieldy and overwhelm the actual code.
Additionally if the scm has the concept of changelists (where many files are grouped into a single change) then you'll be able to write the comment so that it applies to the whole change and not just the edits in the one file (if that makes sense), giving you a clearer picture of why the edit was required.
Yes; let the source control system handle your changeset comments. The rationale for this is that it makes considerably more sense when you're viewing the change log later, trying to work out what's going on between two versions of a file - the source control system can present the change comment to try and enlighten the situation.
There's no reason to manually maintain a file history when SCM software is much better suited to solve this problem. All too often I see partially-completed file histories in the source, which actually hurts, because people incorrectly assume it is accurate.
The difference is not whether it's a centralized or distributed VCS, it's more about what's being changed.
When I moved to .Net, the number of files updated for any individual change seemed to skyrocket. If I had to log the change in each file, I'd never get any real work done. By commenting on the set of changes, it doesn't matter how many files I had to update.
If I ever needed to identify all of the changes for a particular change, I can diff between the two versions of the project.
The biggest difference (and advantage) I saw when switching away from SourceSafe was the switch from file based to project based commits. As soon as I got used to that, I stopped adding change-log type comments to all of my files.
(As a side effect, I've found that my process description comments have gotten better)
I'm not a big proponent of littering the code with change comments. In the event they are needed they can be looked up in the SCM (at least for the SCM variants I have used). If you do want them in the file, consider putting them at the end instead of the beginning. That way you won't have to scroll down past the (uninteresting, to me at least) comments before you get to the actual code.
Another vote for letting the SCM system handle the checkin comments, but I do have one thing to add.
Some systems allow you to use RCS tags in your source code where the SCM can insert the change history directly into the source file being committed automatically. Sounds like a nice balance because the history is then in the SCM system and then automatically put into the source code itself.
The problem is that this process changes the source file. I think that's a bad idea because the file cannot be changed on disk until after you comment is inserted. If you were a good engineer, you should have built and tested changes before the commit. If your source changes after the commit, then you've essentially got a build that could be broken - but most engineers won't build after a commit - why should they?
But it's just a comment you say! True, but I did have a case where there was code in my source file that strangely enough had reason to look like an RCS header tag and that section of the code got replaced on checkin, thereby munging my code. Easy enough to fix, but bad that a build got broken for 20+ users
Much easier to forget to maintain history in the source, as one always (imo) should comment commits to source control system that problem dissappers. Also if changing lots of files before commit, changing history in every file will be annoying work. This is really one of the points with having scm.
I have experience with this. I've had the file history in the comments, it was awful. Nothing but garbage, sometimes you would have to scroll down almost 1k lines of code changes before you finally got to what you wanted. Not to mention, you're slowing down other aspects of your build process by adding more kb to your source code tree.