Author Topic: Support for 3rd-party Diff  (Read 2382 times)

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Support for 3rd-party Diff
« Reply #15 on: December 28, 2015, 06:58:09 pm »
@Clark, just use BC for a while.  You'll see what we mean.  Once you've used BC to merge a conflict consisting of interleaving changes to a single function, you'll wonder how you lived without it.
As noted, you can align individual lines in the compare, which can really help isolate the real changes from the resync noise that every diff tool I've used suffers.  At least with BC, you can help the tool get unconfused.
This is no criticism, just an observation:  You appear to prefer to live in a text/CLI world, and I haven't observed much appreciation of eye candy, so maybe what we like about BC won't be as valuable to you.
It's incredibly valuable to those of us who use it.

Tim Kemp

  • Senior Community Member
  • Posts: 537
  • Hero Points: 91
Re: Support for 3rd-party Diff
« Reply #16 on: December 28, 2015, 07:42:32 pm »
I agree with the group here that think BC is better than DIFFzilla. I own a copy of Beyond Compare. At work, I use Araxis Merge. It has some features that I feel make it nicer to use that BC. Personally, I can't justify the cost of a personal copy of AM for myself, but if the prices were closer I'd take AM.

Another reason, besides those already given, that I have to use AM at work: compatibility. There is a feature in AM that lets you save all of the open compared files and the current settings in a single "workspace" file. We exchange those files to do small code reviews. I'm sure there are better methods, but it works pretty well for a few files. It is convenient to work with a single file and also ensures that everyone is reviewing exactly the same thing.

A nice extension to the DIFFzilla launcher would be if in addition to files you could also compare clipboards it would allow comparing small pieces of the same file or different files. I often create a couple of temporary files, paste the pieces I want to compare into them and use DIFFzilla on those buffers. If this was automated it would save me a couple steps and make it more obvious to others how to do this common task.

b

  • Senior Community Member
  • Posts: 308
  • Hero Points: 26
Support for 3rd-party Diff
« Reply #17 on: December 28, 2015, 10:53:29 pm »
Does this work if all that happened in a file was one function changed?

It's all dynamic and allows you to make comparisons on the fly. 


Interesting. There are some workarounds.

If you move a function, you could do a symbol diff. A resync would be nice since it has the advantage of handling more than just the one function symbol.

There are some non-diffzilla compare commands which can come in handy. I almost always use them when I need to compare two parts of the same file (yep you heard right). The commands are "compare" and "compare-options". No where near the power of DIFFzilla but these are very useful. the "compare-options" command displays some simple but useful compare options.

To use the "compare" command, close all edit windows, open the first file, do a split window, and open a second file (unless comparing parts of the same file). Put the cursor location where you want to start the compare in both windows. Now invoke the "compare" command. I think it's bound to F6. There is a "resync" command but I haven't used it and don't remember what it does (maybe finds lines which match). Whatever it does it's very primitive. After the mismatch, just adjust the cursors in each window and do another compare.

This will work for your XML example and will also work when you want to compare to parts in the same source file (that's what I use it for).

I was playing with the compare command, but my development use case is that I have dozens of open editor windows that I'm constantly referencing and flipping through.  The thought of having to close them all to make this work is quite revolting when I can pop open a diff and see my own going work, copy/paste/change and then continue my development.  Moreover, I tend to use diffs against my repo (what have I since my last commit vs SE's great feature of what did I change since my last save?), and the use of the compare command against the repo version wasn't clear.

I've also not been thrilled with the very restrictive 3-way merge of vsmerge (apparently all or nothing with no edit capability discovered) and so I tend to use kdiff3 or other tools.  There are many times where I want to alter what is to be copied to make the merge make sense.  The selective line copy/delete feature along with inline editing of the base diffzilla would be plus over the vsmerge (and have resorted to manual 3-way merge evaluations with diffzilla in a pinch).

Of course, having this integrated by either a choice of using other tools (as many version control systems do), or SE swiping the best features of other tools for your own would be preferred.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5177
  • Hero Points: 429
Re: Support for 3rd-party Diff
« Reply #18 on: December 28, 2015, 11:27:11 pm »
Yes, I agree with what b said. Also I would like to add that other functionalities it has, is that you can choose how you want to compare your files. You can put some rules to tell it what can be ignored, or do a line by line comparison. I don't know of a way to do this with Slickedit.
Rules to include or ignore lines would be great. Not sure what you mean by line by line comparison. I thought that's what all diff tools did.