Compare menu

[Michael Bulgrien]

I expect that the Scooter team's initial response to this request will be negative. Nevertheless, please seriously consider this idea. I've thought about it many times and it would make BC3 so much easier to use.

In my environment, most folder compares must be CRC-based because other tools I work with do not preserve date/time stamps (Microsoft Visual Studio Team Foundation Server source control, for example.) However, I have other responsibilities that have me working with deep folder structures containing very large files that could be compared via date/time stamp...and my productivity plummets because it takes far too long for the default CRC compare to bring back the results of a recursive CRC compare.

It is too cumbersome to always have to go in and edit session rules whenever I need to change comparison criteria. Please consider adding a Compare drop-down menu to allow a user to easily change compare criteria on-the-fly:

Compare

Timestamps (toggle)

Contents

Size
CRC
Binary
Rules

Attributes

Archive
System
Hidden
Read-only

Just like adding a "Flattened Folders" option to the View menu would be a useful shortcut to setting session rules, so would an easy-access compare menu. For fine-tuning (timezone considerations, etc.) the user would still need to go to the session rules dialog.

[Aaron]

Not too negative

Actually, the design for under the Rules/Referee button is not quite done. It currently implements a method similar to BC2. It works well and gives a lot of options to the user, but does not present the information intuitively to a new user.

This may or may not be a 3.0 feature, but what do people think of the Refree button's Rules dialog on the Folder Compare, and how the options under it are presented? Thoughts on making it more intuitive, without losing any of the control of BC2?

Michael - While this doesn't directly relate to your dropdown boxes, that interface either could be worked out before hand, or a change to it may solve some of your issues altogether.

[Michael Bulgrien]

While this doesn't directly relate to your dropdown boxes, that interface either could be worked out before hand, or a change to it may solve some of your issues altogether.

An easy way to solve some of my issues:

When I select a group of opposing folders and choose "Compare Contents" from the context menu, please add an option for Size and Timestamp. This would allow me to override my default compare settings:

[Aaron]

Size and Timestamp

Size and Timestamp is not considered a Content Comparison. When we run that option, by default, it does not fill in the middle Content Column with information.

In your example, you mention you have some folders that you use commonly that need CRC comparisons (because timestamps are not preserved). You have other tasks that often have many more files, and where timestamps work fine.
You also mention editing your session rules' comparison criteria (assuming you are not changing other values).

The previous example seems to imply different sets of folders, and the second implies the same set of folders needing to switch from Timestamp/Size to CRC. Could you explain the workflow and how you currently use BC to meet your needs? Would two folders of identical sessions (one folder be CRC, one be Timestamp/Size) not help?

[Michael Bulgrien]

Size and Timestamp is not considered a Content Comparison. When we run that option, by default, it does not fill in the middle Content Column with information.

I don't care if the middle column does not get filled in. I want the sub-folders to color to show whether or not there are any potential differences in the sub-folder tree.

This is my scenario:

1) Most of my work deals with files where time/date are not preserved, so my default comparison criteria is set to Size and CRC.

2) I work with deep tree structures. Recursive compares are VERY slow and painful with CRC checking enabled! At Scooters suggestion, I have disabled the "Automatically scan subfolders in background" Folder Handling option for my default folder session settings. This means that all sub-folders on both sides of the compare show up as yellow...so I have no idea if any content under those subfolders differ.

3) I have a few servers that contain mostly "mirrored" data with a huge folder tree structures and a good number of files far exceeding 100 meg in size. A CRC scan in these scenarios can run for hours! It actually takes less time to just overlay the entire folder structure on the second machine with the contents of the first machine, but that also takes a couple hours!

4) I want to do an initial Timestamp scan to eliminate/filter out the majority of files that are identical, then follow up with a CRC scan to eliminate any files that are the same except for the timestamp. I do not want to edit session settings to swap back and forth between Timestamp and CRC checks.

Please allow me to compare folder content on the fly as requested in my original post. I would not expect the Size and Timestamp option to show up for a "Compare Contents" operation initiated against two opposing files... But I need the flexibility to do an on-the-fly Size and Timestamp comparison of folder contents. I am intelligent enough to know that a Size and Timestamp compare does not guarantee file uniqueness. I do not expect the middle "content column" to be updated. I do expect folder/file colors to be recursed through the sub-folder structure and items that have identical size and timestamps to be filtered if I have a difference-only filter in place.

I am sure one option would be to set up my session settings as follows:

...so that CRC checks don't override the timestamp comparison. But once again, this means that I have to go in and out of session settings any time I want a true CRC compare that does override timestamps. If you give me the option in the Compare Contents dialog, then I can override my session settings at will and know that my defaults remain the way I want them.

[Chris]

Michael,

First, try using binary comparison instead of CRC. CRC comparison has to read the entire contents of each file before it can generate a comparison result. Binary comparison only reads the file contents until it finds a difference. For large files with lots of differences, this can make the comparison much faster.

The only time when CRC comparison should be chosen over binary comparison is if at least one side has precomputed CRC values. BC can use precomputed CRC values from zip files, BC snapshots, and FTP servers that support the XCRC command.

Also, why not use two saved sessions? One session with "Override timestamp comparison" checked, and another saved session with it turned off?

[Tim]

Chris' points on binary comparisons are valid, but they won't help much with your huge mirrored environments. And I'd guess you don't care for the 2 sessions idea.

I think I understand your workflow enough for us to knock around some ideas that may help.

Thanks,

[Michael Bulgrien]

try using binary comparison instead of CRC.

Thanks for the explanation. That certainly should help.

why not use two saved sessions?

As useful as pre-configured sessions may be, having to swap back and forth between two different sessions is neither practical, nor efficient, nor intuitive. Frankly, I don't even know why I have to say this...to me it is just plain common sense. When I am working in a folder compare session, I prefer an efficient way to do what I need to do in that session without having to leave the session to load everything in a different session...and without having to change session settings back and forth to get the job done.

A dialog that already provides options for the user, but lacks a related option that would make life so much easier for someone working with large folder structures, seems a logical place for an enhancement. Other than using Binary instead of CRC, your proposed work-arounds result in more tedious effort and organization on my part.

P.S. By the way, the current order of the comparison options are misleading, in my opinion. It gives the impression of progressively more complex comparison options. If a CRC compare is more resource intensive than a Binary binary compare, wouldn't it make sense to list it after Binary?

[Zoë]

CRC compares are not always more resource intensive than binary compares. They're roughly equivalent at different points. If the CRC comparison is already calculated, in zips, for example, or if they can be computed on the server (FTP's XCRC command) then it's much faster than performing a binary comparison, and in those cases a binary comparison has to read the whole file from the original source first anyway, so it can't break out significantly faster than CRCs even if there is an early difference.

As for your original suggestion, would it work for you if we added an option to the comparison control to only perform a content comparison if the sizes or timestamps differ?

[Michael Bulgrien]

would it work for you if we added an option to the comparison control to only perform a content comparison if the sizes or timestamps differ?

I guess you mean a check box rather than an option. Yes, that should suffice...so long as the result is that files with the same size and timestamp are filtered when a differences only filter is enabled. In other words, if all sub-folders and files have the same size and timestamp, I would expect the folder to turn gray.

[Tim]

Michael,

In build 443 we've tinkered with the comparison criteria settings. I am interested in hearing if this combination would work for your typical source projects:

• [ ] Automatically scan subfolders
• [ ] Expand subfolders when loading session
• [x] Compare file size
• [x] Compare timestamps
• [x] Compare contents
• ( ) CRC comparison
• (x) Binary comparison
• ( ) Rules-based comparison
• [x] Skip if quick tests indicate files are the same
• [x] Override quick test results

In particular, I'm trying to provide and environment where you don't need to use the Compare Contents command at all. The slower comparisons would only be performed when you access folders. Imagine also a new Scan Subfolders command that would be available to selectively color the unscanned subfolders. (For now you can press the keypad + to expand the a subfolder and then - to collapse it again.)

[Michael Bulgrien]

In particular, I'm trying to provide and environment where you don't need to use the Compare Contents command at all.

Thanks, Tim

As much as I appreciate your goal, whether I need to use the Compare Contents command is irrelevant when it comes to the other issue I reported which deviates from industry standards:

If a command requires additional information to complete its intended action, and you use a dialog box to supply that information, follow the command with an ellipsis (...). The ellipsis provides a visual cue that the command requires additional information.

and

Label a button Cancel if canceling returns the environment to its previous state (leaving no side effect)

Since, in the situation I described, a content compare starts without the "Compare Contents" dialog returning additional information, the "ellipsis" is improperly used.

And since cancelling the dialog does not leave the environment in its previous state, the "Cancel" button is improperly used.

I don't want the "Compare Contents" option removed. I do anticipate that I will want to use it from time. I just want the design standards adhered to in this scenario.

[Tim]

Thanks, but I'm not asking about Compare Contents right now.

[Michael Bulgrien]

Quick tests
[x] Compare file size
[x] Compare timestamps

Requires opening files
[x] Compare contents
( ) CRC comparison
(•) Binary comparison
( ) Rules-based comparison
[x] Skip if quick tests indicate files are the same
[x] Override quick test results

I've tested these settings. They do, indeed, speed up remote to remote compares. Thank you. I do indeed like having both a Quick Compare and a Compare Contents option in the context menu.

That being said, launching the "Compare Contents" dialog on a subfolder still starts the compare without the user completing the "Compare Contents" dialog and still leaves the environment in a modified state when the user clicks the Cancel button.

[Michael Bulgrien]

In other words, yes, the new quick test option works great! It fully addresses the issue I initally reported in this thread by eliminating the need for a "Compare Contents" action when a "Quick Compare" is desired.