DiffMerge 3.3.0 Now Available

Support for our DiffMerge utility.

Moderator: SourceGear


Posts: 534
Joined: Tue Jun 05, 2007 11:37 am
Location: SourceGear
PostPosted: Thu Apr 09, 2009 9:08 am
SourceGear DiffMerge 3.3 is now available.

Full details can be found at http://www.sourcegear.com/diffmerge/index.html.

The previous release was 3.2.

Enjoy.
jeff hostetler

Posts: 3
Joined: Sun May 31, 2009 2:07 pm
PostPosted: Mon Jun 01, 2009 4:35 pm
I really don't like the new annoying message box (MERGE-RESOLVED, MERGE-ABORTED, ERROR) I get during merge if using /result. Pleeeeeeease provide an option to turn this dialog off (add a new setting for this dialog like you have for the other dialogs that can be turned on\off). I also miss a onn\off setting like this for the dialog I get when one of the files have changed and DiffMerge ask if it should reaload the file(s), at least for the case where I didn't edit anything (no pending changes) -> just reload without asking. Have reverted back to the previous version for now, hopefully the next version will be better.

Posts: 534
Joined: Tue Jun 05, 2007 11:37 am
Location: SourceGear
PostPosted: Wed Jun 03, 2009 8:14 am
WRT the MERGE-RESOLVED... dialog. You should only see this if you
did not save the merge result. Either because you never saved the
window (so the result file hasn't been created) or because you did do
a save and then made more (unsaved) changes in the window (so the
result file that was created is now stale). In both of these cases, it is
important to ask what your intentions are so that the exit status can be
set correctly so that the invoking application does the right thing.

Some invoking applications pre-create the result file in a temp file and
expect the gui merge program to overwrite it with the actual merge result.
Some invoking applications do not pre-create the result file and expect
the gui merge program to create it.
Some invoking applications use the version of the file in the working
directory as the merge result and expect the gui merge program to
overwrite it. So if you close the window in a dirty or unsaved state,
it is not clear whether DiffMerge should do and it is not clear whether
DiffMerge should delete/restore the result file. In the case of intermediate
saves and unsaved work, do you want to keep the saved changes but not
the last few edits or do you want to abort the entire merge? These
things cannot be magically determined.


WRT the auto-reload question, yes I can log a feature request to just do
the reload without asking when the buffer is not dirty.

jeff

14379

Posts: 3
Joined: Sun May 31, 2009 2:07 pm
PostPosted: Wed Jun 03, 2009 11:39 am
WRT the MERGE-RESOLVED... dialog. You should only see this if you
did not save the merge result. Either because you never saved the
window (so the result file hasn't been created) or because you did do
a save and then made more (unsaved) changes in the window (so the
result file that was created is now stale). In both of these cases, it is
important to ask what your intentions are so that the exit status can be
set correctly so that the invoking application does the right thing.

Yes, but the way I use DiffMerge (with TortoiseSVN), it\I don't care about the return status and I manually resolve the file.

Some invoking applications pre-create the result file in a temp file and
expect the gui merge program to overwrite it with the actual merge result.
Some invoking applications do not pre-create the result file and expect
the gui merge program to create it.
Some invoking applications use the version of the file in the working
directory as the merge result and expect the gui merge program to
overwrite it. So if you close the window in a dirty or unsaved state,
it is not clear whether DiffMerge should do and it is not clear whether
DiffMerge should delete/restore the result file. In the case of intermediate
saves and unsaved work, do you want to keep the saved changes but not
the last few edits or do you want to abort the entire merge? These
things cannot be magically determined.

I agree, but getting two dialogs in a row is not very user friendly. I think it should have been solved by using a single dialog, but with one extra button: "Do you want to save changes?" "Yes" (RESOLVE-MERGE), "No" (ABORT-MERGE), "No, but resolve anyways" (RESOLVE-MERGE), "Cancel". In addition, with an extra setting (command line option!) it should be possibly to say I don't care about the RESOLVE-MERGE\ABORT-MERGE exit statuses (actually, this should have been an opt-in feature, so people could turn it on, not off!) and then it wouldn't show the "No, but resolve anyways" button. Everyone is happy.

WRT the auto-reload question, yes I can log a feature request to just do
the reload without asking when the buffer is not dirty.

Great. Lookin forward to it. DiffMerge rules.

Gunnar.

Posts: 534
Joined: Tue Jun 05, 2007 11:37 am
Location: SourceGear
PostPosted: Wed Jun 03, 2009 12:13 pm
True, I could combine those 2 dialogs and streamline the process.

I'll log this too.

jeff

14384

Return to Support (DiffMerge)

Who is online

Users browsing this forum: No registered users and 4 guests