## kdiff3-user — User questions about KDiff3.

You can subscribe to this list here.

2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 Jan Feb (2) Mar (30) Apr (22) May (8) Jun (6) Jul (4) Aug (3) Sep (14) Oct Nov (14) Dec (3) Jan (12) Feb (5) Mar (8) Apr May (9) Jun (2) Jul (9) Aug (9) Sep (4) Oct (18) Nov (9) Dec (6) Jan (3) Feb (6) Mar (5) Apr (7) May (7) Jun (7) Jul (2) Aug (5) Sep (18) Oct (10) Nov (6) Dec (1) Jan (13) Feb (9) Mar (20) Apr (7) May (3) Jun Jul (7) Aug (7) Sep Oct (8) Nov (16) Dec Jan (6) Feb (1) Mar (1) Apr May Jun Jul (6) Aug Sep Oct (2) Nov Dec (3) Jan (22) Feb (15) Mar (7) Apr May (2) Jun (3) Jul (1) Aug Sep Oct Nov Dec Jan (4) Feb Mar (3) Apr (1) May Jun Jul (8) Aug (1) Sep Oct Nov (1) Dec Jan Feb (9) Mar Apr (3) May (4) Jun (2) Jul (1) Aug Sep (8) Oct (2) Nov Dec Jan Feb (2) Mar (1) Apr May Jun Jul (1) Aug (8) Sep (2) Oct Nov Dec (4) Jan (3) Feb Mar Apr (4) May Jun (1) Jul Aug Sep (1) Oct Nov Dec (1) Jan (2) Feb (2) Mar Apr May Jun Jul (1) Aug (6) Sep (1) Oct (1) Nov Dec (1) Jan (9) Feb Mar Apr (3) May (1) Jun Jul Aug (1) Sep (1) Oct Nov Dec
S M T W T F S
1

2
(2)
3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18
(1)
19

20
(1)
21

22

23
(1)
24

25

26

27
(2)
28

29

30

Showing 7 results of 7

 Re: [Kdiff3-user] diff/merge algorithm improvements From: Joachim Eibl - 2007-04-27 21:03:59 ```Hi Fran=E7ois, A feature like you suggest is on my todo list, because I know that it would= =20 yield many benefits. But I'm very careful to modify the core algorithms because it took a long t= ime=20 to get them to be as stable as they are now. The same probably applies to original GNU-diff. So I think your chances wit= h=20 KDiff3 are not so bad. But if the original GNU-diff is extended in such a w= ay=20 I will gladly upgrade KDiff3 as well. As for the algorithm: One important reason, why this is not a standard feat= ure=20 yet, is that there is no really universal and fast algorithm. A line based= =20 diff can be fast because it compares hash values for equal lines, but if=20 lines are not equal the complexity grows quadratically with the maximum=20 distance where a match is searched for and a single comparison already take= s=20 long. So I would make it an optional feature only. I'll investigate. Joachim Am Freitag, 27. April 2007 17:46 schrieb Fran=E7ois Cerbelle: > Hi, > > I searched throught the list but did not find a similar question to mine. > The test files are : > a.txt b.txt c.txt > DEF DZF ABC > GHI GHI DEF > GHI > > When I use KDiff3 with: > - a and b, it detects that the first line whas modified : OK. > a b > DEF DZF > GHI GHI > > - a and c, it detects that a new line was added in c : OK. > a c > ABC > DEF DEF > GHI GHI > > - b and c, it detects that the first line changed and that a new line was > added : it is true, but not optimal. > b c > DZF ABC > DEF > GHI GHI > > a more logical diff would be : > b c > ABC > DZF DEF > GHI GHI > > - a, b and c : KDiff align DEF(a) with DEF(c) but not with DZF(b), it > aligns DZF(b) with ABC(c), which is not very logic (from a user point of > view). In fact, it would be more accurate if the result was : > a b c > DZF ABC > DEF DEF > GHI GHI GHI > > a more logical diff would be: > a b c > ABC > DEF DZF DEF > GHI GHI GHI > > We encountered theses behaviours when using the couple > Mercurial(hg)/KDiff3 to manage our source repository. Such "more logical" > or "more smart" diffs would be very useful to merge files. > > I think the problem comes from the GNU Diff lib as "vimdiff" (part of > "vim") has the same behaviour. But as you changed the GNU diff lib, if I > submit the problem to the GNU Team, I am not sure the fix (if they do) > will go into KDiff3. > > What do you think ? Is it technicaly possible to do such a diff ? Who > should do it (KDiff or GNU) ? Such a diff does not break the "spirit" of > diff/KDiff ? > > Have a nice day > Fran=E7ois ```
 [Kdiff3-user] diff/merge algorithm improvements From: - 2007-04-27 16:14:41 ```Hi, I searched throught the list but did not find a similar question to mine. The test files are : a.txt b.txt c.txt DEF DZF ABC GHI GHI DEF GHI When I use KDiff3 with: - a and b, it detects that the first line whas modified : OK. a b DEF DZF GHI GHI - a and c, it detects that a new line was added in c : OK. a c ABC DEF DEF GHI GHI - b and c, it detects that the first line changed and that a new line was added : it is true, but not optimal. b c DZF ABC DEF GHI GHI a more logical diff would be : b c ABC DZF DEF GHI GHI - a, b and c : KDiff align DEF(a) with DEF(c) but not with DZF(b), it aligns DZF(b) with ABC(c), which is not very logic (from a user point of view). In fact, it would be more accurate if the result was : a b c DZF ABC DEF DEF GHI GHI GHI a more logical diff would be: a b c ABC DEF DZF DEF GHI GHI GHI We encountered theses behaviours when using the couple Mercurial(hg)/KDiff3 to manage our source repository. Such "more logical" or "more smart" diffs would be very useful to merge files. I think the problem comes from the GNU Diff lib as "vimdiff" (part of "vim") has the same behaviour. But as you changed the GNU diff lib, if I submit the problem to the GNU Team, I am not sure the fix (if they do) will go into KDiff3. What do you think ? Is it technicaly possible to do such a diff ? Who should do it (KDiff or GNU) ? Such a diff does not break the "spirit" of diff/KDiff ? Have a nice day François -- Bat. B10 - 6 r d'Andilly - 95600 Eaubonne SFR : (+33/0) 603 015 512 - FBX : (+33/0) 871 777 756 ```
 [Kdiff3-user] Ignored subdirectories deleted during merge From: Vladan Bato - 2007-04-23 12:31:01 ```Hi, I have the following problem: I'm trying to merge three directories under CVS control and I have configured kdiff3 to ignore the subdirectories named CVS. If I choose to put the results of the merge in directory C, kdiff3 will delete some of the ignored CVS subdirectories instead of leaving them alone. This happens for the directories where the "A" or "B" merge operation is chosen for the entire directory. The workaround I found is to select "Do nothing" for the directory, and then manually set "A" or "B" for each file, but this is really tedious. Shouldn't selecting the "A", "B" or "C" operation for a directory mean that it should be applied to individual files instead of the directory itself? A similar thing happens if the option to create .orig backup files is active. In this case the original directory at the destination will be renamed into .orig, and the corresponding directory from "A" or "B" copied over (but without the ignored files). Here again I lose the CVS subdirectory. Is this the intended behavior, and can it be changed? Or is there another way to do it? Thanks, Vladan. -- Vladan Bato vbato@... ```
 [Kdiff3-user] feautre requesti/question From: Andrej Sarkic - 2007-04-20 17:46:46 ```One thing I have not been able to do in KDiff is swap the left and right side in merge mode. I am not sure if this feature exists or not. It is useful when you're looking at a diff from source control (I integrate with ClearCase), and one version is in source control, hence read-only, while the other is locally checked out or hijacked, so it is writable. I would like to go into merge mode, and make some tweaks to the local copy w/o doing an actual merge. However the default setting puts the original on the left, and the new on right, so that when I go into merge mode, the resulting file is the read only copy. It would be very useful at that point if I could swap the left and right side, and thereby choose to write to the other file. Does this make sense? Thanks, Andrej __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ```
 [Kdiff3-user] KDiff3-0.9.92 released From: Joachim Eibl - 2007-04-18 21:18:52 ```Hi KDiff3-users, In the last few months I didn't have much time to spare for KDiff3 so I am glad to be able to announce another version, even if it doesn't contain that many new features. Two integration features made it: - Simplified installation of KDiff3 for Clearcase under Windows. Some users know that KDiff3 can be used with IBM Rational Clearcase. Up to now the setup had to be done manually by editing the map-file. Now you can let the installer do this, or enable or disable this later from within KDiff3. KDiff3 can replace the text-file diff and merge for ascii (or unicode) files. - Konqueror service menu plugin for KDiff3. When I wrote it I didn't realise that Sergey Zorin also ported his Diff-Ext-tool to KDEs Konqueror and to Gnome's Nautilus. And his tool can be configured to be used with other diff-frontends too. So now you even have choice. Otherwise I mostly fixed some bugs. Here is the Changelog: Version 0.9.92 - 2007/04/15 =========================== - Windows installer now allows to install KDiff3 as Clearcase Diff and Merge Tool - Windows installer "SVN Merge tool" corrected: Not creating \$AppData\Subversion\config subdir anymore. - KDE-Konqueror plugin: Launch KDiff3 from Konqueror. (Similar to Diff-Ext on Windows.) - Qt4-version - Printing crash fixed - Compilation issue for Mac fixed - Dir Rescan keeps settings for Show identical files etc. - Bugfix: Empty file and not existing file were detected as binary equal. - Temp file names use the process id in file name to allow several instances. - Suppress flicker during startup. (Don't show status info window on creation.) - New File comparison mode: Trust the size and date, but use binary comparison if date doesn't match (unsafe) - After explicitely selecting files any file of the selected may be right clicked for context menu. - Open dialog also shows current directories in directory comparison mode. - Writing a file via --auto option didn't work for relative files. - New option for history merge: Max number of history entries - New option "Auto save and quit on merge without conflicts" - Directory Merge without Case sensitivity: Correct destination filename chosen for merge. The windows-installer should even work if you don't have admin-rights (by specifying a directory for which you have write access and disabling the "Install for all users"-checkbox later). Nevertheless I was persuaded to also provide a zip-file with the executables, but of course the automatic integration with other tools isn't possible then. The Mac Universal binary was created again by Michael Schmidt. (Thanks!) Have fun, Joachim ```
 Re: [Kdiff3-user] Command line Output From: Vladan Bato - 2007-04-02 08:32:45 ```nitin jindal wrote: > I am working on a project for which I have to compare a lot of files and > automatically process the comparison results. So, my question is can > kdiff3 be configured to give output in command line, instead of > displaying in a gui. You should probably use diff. It runs from the command line and can output the differences in several formats suitable for processing by other programs. The purpose of kdiff3 is to show the differences visually and allow you to interactively merge the files. If you are using Linux, diff is already installed. If you are using Windows, here you can find a Windows version of diff (and other programs from the diffutils package): ; -- Vladan Bato vbato@... ```
 [Kdiff3-user] Command line Output From: nitin jindal - 2007-04-02 01:00:43 Attachments: Message as HTML ```Hi, I am working on a project for which I have to compare a lot of files and automatically process the comparison results. So, my question is can kdiff3 be configured to give output in command line, instead of displaying in a gui. Thnx and regards, Nitin ```

Showing 7 results of 7