Two questions:
How to make the TortoiseSvn diff tool ignore the EOL style?
How to fix mixed EOL style files during the conversion from PVCS to SVN?
I've just imported a PVCS archive to Subversion using the excellent free Polarion conversion tool. Everything looks fine, there is just one annoying thing that I'd like to fix.
Some of the cpp files in the original PVCS archive have mixed EOL styles (due to the PVCS merge tool). These files (and all their revisions) are now copied into the Subversion archive using the autoprops setting "svn:eol-style=native".
When I use the TortoiseSvn diff to see a difference between two versions I get the error message "Inconsistent line ending style".
The whole idea of converting 10 years of revision history from PVCS to Subversion is to make it easy for the programmers to see what changes were made in the past - and if you need to clean-up an old file manually before a diff is possible, it's not going to work.
WARNING: The REAL problem with the EOL styles is in the java converter that reads the PVCS repository and generates the Subversion dump files. It takes the autoprops settings and applies them to the file types you specified - in my case the eol-native property - EVEN if the files have mixed EOL. Normally svn checks for this on commit and makes sure that files are cleaned-up before they are committed.
Lesson learned: Do NOT use the eol-stype autoprops when converting from PVCS to subversion. If you need it then add it after the conversion is completed and get the files cleaned in the process.
I use WinMerge as Tortoise’s diff tool and it has an option to treat all EOL styles as equivalent.
WARNING: The REAL problem with the EOL styles is in the java converter that reads the PVCS repository and generates the Subversion dump files. It takes the autoprops settings and applies them to the file types you specified - in my case the eol-native property - EVEN if the files have mixed EOL. Normally svn checks for this on commit and makes sure that files are cleaned-up before they are committed. Lesson learned: Do NOT use the eol-stype autoprops when converting from PVCS to subversion. If you need it then add it after the conversion is completed and get the files cleaned in the process.
Related
I use Perforce to manage a project that contains some binary files (Excel, Word and Visio diagram files).
I'd like to know the safe way to update my local version of such files from the latest version available on Perforce, without corrupting/damaging/overriding the local changes. (Local changes are made locally and not submitted to Perforce yet)
Locks don't seem to solve the problem because it helps only in concurrent submission of files.
p4 reconcile to make sure that any local changes are correctly reflected in your pending changelist(s).
p4 sync as normal. Opened files will not be overwritten by a p4 sync.
If you're following the standard Perforce workflow of always opening files for edit before you modify them (i.e. you never override the "read-only" flag on your local files), you can skip step 1 and just sync at any time without fear.
p4 resolve to handle any files that have been modified both locally and in the depot.
Note that Perforce's built-in merge logic will only handle text files, and so resolve will by default offer only a binary yours/theirs choice for binary files (at will overwrite your local changes, and ay will ignore the depot changes). If you have a merge tool that can handle your binary format, you can do:
p4 set P4MERGE=your_merge_tool
p4 resolve -t
m
to invoke your merge tool as part of the resolve process. See the documentation on the P4MERGE variable for more information how this tool will be called (you may need to wrap it in a script if it doesn't follow the base theirs yours merged calling convention): https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef/P4MERGE.html
I'm using TortoiseSVN 1.7 and want to create patch file between two revisions.
I've searched, but these threads How do I create a patch from diff between revisions using TortoiseSVN? Creating a patch between two revisions do not work for me, as Show changes as unified diff generates very simple file (not a patch file). Something like
Index: myfile.txt
===================================================================
I read in Viewing Differences that
If you want to see the changes made to all files in a particular
revision in one view, you can use Unified-Diff output (GNU patch
format). This shows only the differences with a few lines of context.
It is harder to read than a visual file compare, but will show all the
changes together. From the Revision Log dialog select the revision of
interest, then select Show Differences as Unified-Diff from the
context menu.
I want to create a single patch file (or many patch files according to modified files) that contains useful diff information (like the menu context TortoiseSVN -> Create patch ...)
If you use the "Show changes as unified diff" command, then TortoiseSVN shows all changes of the selected revision in a single file.
Now simply use the "File / Save as" command to save the changes to a ".patch" or ".diff" file and there you have your patch file.
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":
Is there a way to tell Perforce to leave text files alone without setting the file-type as binary? Or barring that, is there a way to tell the Perforce client to diff binaries? Binary usually isn't desirable, because I lose the ability to diff.
To clarify: If I edit and make changes to a *.txt file on my window client, newlines will have CR+LF as per the DOS format. But if I P4 sync on a Unix client, it will have LF only. I need Perforce to keep the format as-is, regardless of where the Perforce client lives.
That said, I do have a work-around: Set file-type as binary; and/or create a branch with text files set as "text", and integrate periodically back into the mainline where text files are set as "binary". But this is an overly-complicated work-around for what should be a very simple problem.
Finally, I'm on Perforce Windows client 2006.2.
Thanks in advance.
Set all of your client/workspace specs to 'unix' line-endings. Then no conversion will take place when you check in on Windows.
See http://answers.perforce.com/articles/KB_Article/CR-LF-Issues-and-Text-Line-endings/
The Perforce client can handle line ending properly when syncing to different platforms provided you have LineEnd option set properly on your client. Perhaps you have yours set wrong? Open up your client specs and set the LineEnd option according to your needs.
Check out this KB article on their website for more info. Here's an excerpt:
On the server side, Perforce processes
all text files using Unix-style LF
line-endings. Although Perforce stores
server archive files on disk in the
operating system's native line
termination convention (CR/LF on
Windows, LF on Unix), all line-endings
are normalized to Unix-style LF
line-endings for internal Perforce
Server operations such as p4 sync, p4
submit and p4 diff.
On the client workspace side, Perforce
handling of line-endings is determined
by a global option for each
clientspec. When you sync text files
to a client workspace with p4 sync, or
submit them back to a Perforce Server
with p4 submit, their line-endings are
converted as specified in the
clientspec LineEnd section.
When adding text files that you want to be considered binary to Perforce, use the command p4 add with the -t option to override the type mapping table. See the documentation here. The example given there is p4 add -t binary file.pdf.
I have just come across exactly the same problem, but have a better solution that does not involve changing client specs (which are international, and not all of which I have write access to).
All of our clients are Windows PCs, but Cygwin is included within the Perforce Depot. Cygwin is a Windows implementation of Unix, and requires that text files use LF for line endings.
A possible solution for older versions of Cygwin is to mount the root using the "text" option, meaning that files can have CR+LF line endings. However, on upgrading to Cygwin 1.7.9, this no longer worked, as mounts are transient unless they are written into /etc/fstab. I did not manage to make this work.
Luckily, the Perforce Guru sitting next to me came up with the solution of changing the filetype to binary+D, which uses the same RCS incremental patch storage as text files, but without the automatic line ending conversion.
I can diff these "text" files successfully between my local workspace and the depot.
Give the files a different extension.
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?