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?).
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.
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.
We need to change to a new VCS system. I can't seem to find one that tracks change comments both per file and per change-set. Currently when we view file history in our present VCS it shows the various check-ins and the comments for the file on that check in and the over-all check-in comment. We are currently evaluating hg and like it, but can't find how to implement this behavior. Can anyone suggest how to do it in hg - or what VCS would allow this feature? Thanks so much.
You can run
$ hg log your-file
with Mercurial to get the history of just that file. It also works for directories or multiple files where you get a log of changesets changing either of the specified files.
Mercurial is actually very efficient for this: despite having repository-wide changesets, it stores the deltas on a per-file basis and this makes it very easy for Mercurial to show you the per-file history.
Hg's commit works on either the changed files you specify or all the files that it finds have changed. That group of files then makes up the changeset and the same commit message will then be applied all. It sounds like you are looking for a super commit to wrap several commits into one bigger commit.
Named branches are the intended method for something like this. You can then have commits with comments that are specific to certain files and the overall branch name is the feature you are grouping together. Through the command line or Tortoise Hg you can select what files are part of each commit.
I organized code incorrectly in a game I'm developing, and intend to move the state update code from GameView class into the Level class. I would like to record this cut-and-paste in some way. I use Mercurial for versioning. Is this possible with Mercurial? Does any other VCS provide this feature?
Reading a bit more and watching Linus' talk about git at Google, as well as reviewing answers and comments, I understand that this is a feature of git's blame command and works by doing heuristics.
I could get this functionality by using hg-git, exporting the Mercurial changesets, and then just using the git blame -M -C command. Is there an easier way that does not involve git?
If it is not, I'll accept an existing answer that mentions git and describes using its functionality best.
git does this automatically. See How does Git track history during a refactoring?
If the level class doesn't already exist you can do it with:
hg copy GameView.ext Level.ext
and then delete from GameView whatever you've moving to Level, and modify Level to reflect the correct name and exclude everything that's staying in GameView.
If Level already existed I don't think there's any good way to do it unless you're willing to extract that code out into its own class that could start out as a copy of GameView and be included (via #include, or composition, or extension) in Level.
I don't think that Mercurial tracks file renames/moves explicitly, at least it's not a part of a changeset (although it can guess where a particular file came from based on it's content).
That being said, I'm afraid that I'm not aware of any VCS that tracks movement of code between files, just addition to the target and subtraction from the source.
Mercurial supports file rename detection as follows:
hg addremove -s 100
The -s means "similarity" and the 100 means 100%. It will look for files whose name has changed but their content remains identical.
I quite often use this command with a 85 or 90% similarity figure. And in combination with the -n switch which allows a dry run (i.e. do nothing but report), it can be very powerful.
Detection of actual moved code is not really possible I don't think.
What I do for this sort of situation is isolate the changes from my other development, then commit the movement in a single commit with a note, "moved function munge() between files.
To my knowledge, no VCS tracks the movement of data. Renames are trackable with git and Clearcase.
I use Tortoise to interact with CVS for source control. When merging it shows you a diff of the files calling the one on your HD "Yours" and the one in the repository "Mine". Or maybe I have that backwards. As you can see that nomenclature confuses me. Then I also have to try to remember which to merge into.
Is there a setting to change that naming scheme? Maybe to "OnHD" and "FinalInRep".
Update 1
Mark Davidson, changing yours and mine
as your prescribed
I haven't tested it but go
TortoiseCVS-Preferences
Tools Tab
Two-way merge parameters
in that it currently has set "%mine"
"%yours", you might be able to change
them to something else, but have not
tested it.
Changes the paths my diff tool looks for, not what CVS calls the file. As such, it doesn't change what CVS displays, it breaks my merge tool.
I haven't tested it but go
TortoiseCVS-Preferences
Tools Tab
Two-way merge parameters
in that it currently has set "%mine" "%yours", you might be able to change them to something else, but have not tested it.