This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
View TFS changeset details in console
I need a report of the difference between two revision inside a TFS project.
I'm building a simple patch system, and from an article I read on #AltDevBlogADay describes this system. It says that if you can get the difference between your last patched revision release and the current revision that needs to be distributed for patching, all the files should be very easy to pick up/add/delete.
I tried googling, even the MSDN help on the tf.exe command line calls, but none of them help. I'm using the tf hist . -r /version:C1~C3 command but it's only producing the name of the committer, the changeset number, and the comment that was left with the changeset, but no details on the individual files, and wheter they were added, created or deleted.
You can use tf diff to extract the differences and output them in a file as the following:
tf diff FabrikamFiber.CallCenter\fabrikamfiber.web\controllers\
/version: c7~c26 >c:\Radwan.txt
For more info, I have create a video that describe how to perform that command.
TF.exe Fast Overview
Take a look at the difference command from MSDN.
Also, a great tool to compare the status of files, work spaces, and history of change sets or files is Team Foundation Sidekicks. This tool is free and very powerful.
Related
We recently implemented mandatory reviews (Helix Swarm) for the files that are checked into our source control (Helix Perforce). For now this also applies to files that are tool generated, InstallShield .ism files in particular. Since they are text files, a classic diff can be reviewed. The quality of such a review of course is poor, because the files are not intended to be human-readable. An alternative is to open the files in the InstallShield editor, but only few people in my team have the needed license which prooves to be a significant bottleneck in review speed.
Because of the aforementioned problems we are discussing to abolish reviews for InstallShield alltogether. I'd like to know if there is a feasable way to review InstallShield files, so that two people can have a look at changes in the installation routine.
For now we have decided to just do simple plausibility checks. Compare what is described in the pull request with what information that can be easily grasped from the presented diff of the XML file.
Example:
Descripion: Add/Update Library xy
Check if added/changed/deleted lines are containing the library name and possibly version.
If lines of seemingly irrelevant files changed, it's a reason to report a possible defect.
This may not be a perfect quality control of what the setup will finally do, but at least we can catch obvious mistakes early on, without the need for further tooling.
You can add 'MsiDiff.exe' as diff application by extension in Perforce to review InstallShield ism files.
MsiDiff.exe can be found in [IS-INSTALLDIR]\System.
Here is how you can add it in Perforce:
Perforce diff application by extension
We use Perforce, recent build (2015.2, we could update to newer if need), on Win2012-R2 server.
We would like full text search to easily find strings across the code base (.cs, .aspx, .less, .resx, etc)
What is an appropriate approach?
The answer should be: p4search
However, where it could be a cool 20-30 minute setup, plan on taking 4+ hours over 1-2 days.
Worse, p4search has been abandoned by perforce. It does not install our run properly on current linux (e.g. Centos 7), requiring edits to startup scripts and general hassle. The indexer gets hung on some files, rdeep diagnostics.
After screwing around w it for a week, we gave up.
So the answer is:
1) Use Open Grok: https://opengrok.github.io/OpenGrok/
or
2) Prepare for a long haul to set up p4search (which, fwiw, also requires perforce Swarm, so you will be setting that up also)
There are lots of such tools out there. Here are two you could start investigating:
Open Grok: https://opengrok.github.io/OpenGrok/
P4Search: https://www.perforce.com/company/newsletter/2014/02/p4-search-search-perforce-server
There is also the built-in p4 grep (perforce docs), with some limitations, see e.g. this good answer to another question, in the server since 2010.1.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to find untracked files in a Perforce tree? (analogue of svn status)
I want to know what p4 command that will show me which files have changed, which files are not checked in, etc.
If you're using perforce properly, "p4 opened" is what you're looking for. It will tell you what files you have opened for change. If you want to be able to change files locally, THEN open them for edit (or delete, etc.,) then you're walking out of the usage patterns that perforce expects users to abide by and you're treading on dangerous ground.
Perforce does provide mechanisms that will allow you to detect these things - if you're going to insist on working this way. "p4 fstat" will allow you to get the expected md5sum for a file from the server. Comparing that with the local md5sum will tell you if the file has changed. You could, alternatively, compare file dates - if the modification date on your local machine does not match that given by fstat, you can be fairly certain that it has changed, but to be certain, you'd have to do the md5sum check.
In the upcoming 2012.1 release there a new command named p4 status that will do the equivalent to that as if you were using SVN.
p4 status
src/tools/this.rb - reconcile to edit //depot/stuff/src/tools/this.rb#3
src/tools/that.rb - reconcile to add //depot/stuff/src/tools/that.rb#1
src/tools/other.rb - reconcile to delete //depot/stuff/src/tools/other.rb#2
For more information, read the announcement on the Perforce Blog.
While awaiting the official 2012.1 release you have basically two options:
Do it yourself using the command line
Use P4Vs "Reconcile Offline Work"
More details can be found in the Perforce KB.
The default patch file viewer is messy (ie. no side by side diff view etc). I tried setting the path of beyondCompare exe in "Settings->Unified Diff Viewer->custom", but beyond compare also behaves same as default diff tool.
Is there a way to atleast allow side by side diff in patch files ? If so, what is the method ?
My aim is to allow emailing of changes so that they can be reviewed before I commit them :)
Mishal
I've never found any, but the solution that I usually use is to simply apply the patch file to a pristine checkout of the tree, and then do a "regular" diff (my preferred tool is diffuse) to review the changes in context.
The problem with "raw" patch files is that they only provide a few lines of context before and after the change, which often isn't enough.
If you don't like the patch, simply revert the changes and don't commit!
Beyond Compare 4 allows you to view patch files created by SVN. The top window in Beyond Compare is a tree structure, allowing you to navigate folders and files by name. Revision numbers are present in the left and right diff windows.
Create the patch
svn diff -r 5922:6116 > CodeReview.patch
Open the patch in Beyond Compare 4
SVN 1.7 I think was released since this answer was posted, and I landed here because I wanted to show my newly created patch file with syntax coloring, a la view unified diff in TortoiseSvn.
It turns out that Notepad++ automatically syntax colors my file correctly if I give it the filetype of "patch"!
Patches have been around a long time but SVN is now supporting them more fully.
See for example the documentation;
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
For how to create a patch file, see this nice document that describes various methods including mine, WinMerge;
http://docs.moodle.org/dev/How_to_create_a_patch#Creating_a_patch_using_WinMerge
If you have access to a Mac OS X machine, PatchViewer sounds like it might do what you're looking for:
http://appledeveloper.com.au/products/patchviewer/
(Disclaimer: I am the author of PatchViewer.)
You can view a diff file (a patch generated by diff tool) using Kompare from KDE environment. I used it before on Linux, but today I found how to install it on Windows. Here is an installation instruction from a blog "Kompare - the only valuable diff for M$Windows":
Go to gnuwin32 diffutils, download and install.
Download kdewin installer and launch it.
After installing kde4win - start kompare and in "Diff" section show him where your diff.exe (from gnuwin32 diffutils) is located.
Restart Kompare and it's ready to use!
You can also add an association with .diff file format and now you can view any diff files. For me it works great.
I like to use KDiff3, it's packed with functions, very user friendly and available for all popular platforms. It can also integrate with TortoiseSVN.
GitExtensions, my favorite Git GUI, also has an option to "View patch file":
I've got a file and a patch for it. I'd like to visually apply the patch, t.i. see how the changes proposed by the patch look in context, make some corrections, and save the resulting file.
What tool can do that?
Neither of the visual diff tools (i.e. meld, diffuse, diffmerge) do what I want: they don't work with patches, they merely merge whole files.
I really like Kompare. It is just a (very nice) graphical interface for diff.
http://www.caffeinated.me.uk/kompare/
sudo apt-get install kompare
Creating and applying patches
Kompare is able to create a patch file
which lists only the differences
between two compared text files A and
B. Further, Kompare can apply a patch
file which was created this way to an
original file A and, in this manner,
recompute the contents of the
corresponding file B. This is a
comfortable utility for passing a
corrected version of a file to a
friend who already has an older
version of the same file, because only
the (relatively small) patch file has
to be delivered and the receiver can
generate the corrected file by
applying the patch to the original
file.
The patches created and applied by
Kompare are compatible to patch files
generated or applied by the command
line interface diff utility, because
Kompare is in fact merely a graphical
front end to diff and the patches are
created and applied by patch, which
gets called by Kompare.
See use vimdiff with a diff file.
gvim original.file +'vert diffpa the.patch'
This will open GVim and split the window, with the original on the left and the patch applied on the right. You can then add, remove, or change hunks, and save the changes. (Well, if you want to create a new.patch you'll have to run diff again, but that's not difficult.)
You may use the emacs ediff mode.
It lets you see and validate each chunk interactively.
For what it's worth, I have this handy script in my ~/bin directory:
#!/bin/bash
if [ "$1" == "--text" ] ; then shift; fi
if diff --brief $1 $2 ; then
exit 0
else
emacs -fn 8x13bold --eval '(ediff-files "'$1'" "'$2'")'
fi
Another option: if you use Eclipse, you can generate and apply patches visually.
The idea with visual diff tools is that you can:
make a backup copy of the patched file (or a new pristine checkout of the whole tree)
apply the patch
use the visual diff tool to review the changes in context
make any desired change to the patched file within the visual diff tool.
Some tools, such as meld or diffuse will automatically diff against the previous committed version of the files.
The key insight is that you CAN apply the patch, they discard everything you don't like as long as you have a backup copy, or if you are working on a clean checkout.
If you feel more comfortable with reading and modifying unified diffs, and just want to have more context for the diff, emacs has a fairly unique feature, which is next-error-follow-mode while viewing a diff file (diff major mode). That shows the context of a diff line in the target file.
On platforms where Kompare (a fairly nice piece of software if KDE is your cup of tea), I agree that Eclipse is a great option.
I have consistently been a reluctant Eclipse user AND I am consistently impressed by how well the tools work (once the platform finally starts up).
On Fedora, I've got just about every front end installed for each of the main version control engines (SVN - also serving my Windows machines, Mercurial, git, etc.);
Meld is quite nice (no patch interface though).
Submerge works well also.
But since Eclipse does know how to apply patches and Working Copy project created itself once I figured out to create the project in the folder containing my working copy, it may become my favorite SVN front end.
I normally use GitExtensions (.NET and Mono) which also supports applying patches interactively. I hope you are already familiar with git.
Edit: Everything mentioned below this line doesn't seem to be available directly in KDiff3. And as I mentioned before: I haven't tried it yet.
GitExtension normally uses KDiff3 as diff tool, which is able to view patches.
http://kdiff3.sourceforge.net/doc/kpart.html
Using it for patches it has only a two window view, (edit) and doesn't support merging :( but it also supports 3 way diff on complete folders etc.
Actually I never tryed it with patches.
Does xxdiff do what you are looking for?
I'd use meld.
Create two copies of the files, one without and another with the patch. Use meld to compare them, and you can see exactly what the patch is changing and make changes as necessary.
Seriously, why is this so hard?