Hide Unimportant Differences bug?
Moderator: SourceGear
Hide Unimportant Differences bug?
In one of my files, a change from '>' to '>=' was considered an unimportant difference. Is this expected behavior?
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
Uh, no that shouldn't be the case. But then again, that depends.
What type of files are they and what are the ruleset settings for them?
Was the change in an area/context considered a "comment" (as opposed
to the "default" and/or "literal" context)?
For example, if it was inside a comment, we might treat it as unimportant
(depending on the settings).
You're probably talking about source code, so the "default" context probably
applies. (If it isn't in a comment or literal, it is in the default context.)
If that is the case, make sure that "Classify Differences as Important (Always Highlight)"
(under the "Default Context Guidelines") is checked at the bottom of the "Content
Handling" page for the Ruleset in question.
If that's not the case (or if I've rambled too much), please post a screen shot
of the region and we can go from there.
thanks
jeff
What type of files are they and what are the ruleset settings for them?
Was the change in an area/context considered a "comment" (as opposed
to the "default" and/or "literal" context)?
For example, if it was inside a comment, we might treat it as unimportant
(depending on the settings).
You're probably talking about source code, so the "default" context probably
applies. (If it isn't in a comment or literal, it is in the default context.)
If that is the case, make sure that "Classify Differences as Important (Always Highlight)"
(under the "Default Context Guidelines") is checked at the bottom of the "Content
Handling" page for the Ruleset in question.
If that's not the case (or if I've rambled too much), please post a screen shot
of the region and we can go from there.
thanks
jeff
Re: Hide Unimportant Differences bug?
Source, not inside a comment. C#. I'll try your suggestion.
Re: Hide Unimportant Differences bug?
Each >= is not seen as a difference. Maybe the double // comment is causing this?
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
A couple of things come to mind:
[a] In that example, DiffMerge is only going to highlight the "=" and not the whole ">="
because that is the only character that is changed/added/deleted.
When you turn on "Hide Umimportant", does the whole line revert to black/white
with no background shading?
[c] I doubt that the "//" is causing any problems, but you might try deleting those
lines and see if that changes anything.
[d] Have you made any changes to the C# Ruleset? If so, you might want to reset
them and see if that changes anything.
jeff
[a] In that example, DiffMerge is only going to highlight the "=" and not the whole ">="
because that is the only character that is changed/added/deleted.
When you turn on "Hide Umimportant", does the whole line revert to black/white
with no background shading?
[c] I doubt that the "//" is causing any problems, but you might try deleting those
lines and see if that changes anything.
[d] Have you made any changes to the C# Ruleset? If so, you might want to reset
them and see if that changes anything.
jeff
Re: Hide Unimportant Differences bug?
[a] That was what I expected, too.
The line has no background shading. Looking closely, the added "=" characters are actually highlighted, but with the Unimportant color.
There is no indicator in the margin that this line changed, and there is no option to jump to this different line. That's the biggest annoyance.
[c] You're right; that didn't change anything.
[d] Defaults.
So they're clearly marked as Unimportant with the default ruleset.
The line has no background shading. Looking closely, the added "=" characters are actually highlighted, but with the Unimportant color.
There is no indicator in the margin that this line changed, and there is no option to jump to this different line. That's the biggest annoyance.
[c] You're right; that didn't change anything.
[d] Defaults.
So they're clearly marked as Unimportant with the default ruleset.
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
Humph!
I created a similar test with a pair of files with a one character difference ("<" vs "<=")
and the line draws with the pinkish background and the "=" is highlighted. Near the
bottom of the window, it says "Changes: 1". When I turn on "Hide Unimportant", nothing
changes. In the status bar, it says "Ruleset: C/C++/C# Source".
If I look at the "Content Handling" page of the C/C++/C# Ruleset, the "Default Context Guidelines"
shows that "Classify Differences as Important (Always HIghlight)" is checked.
When I turn that off, I get behavior similar to what you are describing. When I toggle
"Hide Unimportant" on the menu, the "Changes: 1" display alternates between that and
"Changes: (0 Imp, 1 Unimp)" and the line is no longer highlighted.
Does this match what you are seeing?
jeff
I created a similar test with a pair of files with a one character difference ("<" vs "<=")
and the line draws with the pinkish background and the "=" is highlighted. Near the
bottom of the window, it says "Changes: 1". When I turn on "Hide Unimportant", nothing
changes. In the status bar, it says "Ruleset: C/C++/C# Source".
If I look at the "Content Handling" page of the C/C++/C# Ruleset, the "Default Context Guidelines"
shows that "Classify Differences as Important (Always HIghlight)" is checked.
When I turn that off, I get behavior similar to what you are describing. When I toggle
"Hide Unimportant" on the menu, the "Changes: 1" display alternates between that and
"Changes: (0 Imp, 1 Unimp)" and the line is no longer highlighted.
Does this match what you are seeing?
jeff
Re: Hide Unimportant Differences bug?
Toggling "Classify Differences as Important (Always HIghlight)" does not change anything. Build 18729, if it matters.
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
The 18729 tells me that you have either Vault 5.0.1 or Fortress 1.0.1. The version
of DiffMerge included with them is feature-wise the same as the standalone 3.3.0
release. So I think we're OK as far as that is concerned and don't need to worry
about upgrading or anything. (BTW, there is a 5.0.2 or 1.0.2 available. But that
shouldn't affect the conversation here because they include the same version of
DiffMerge (albeit with a different build number).)
Could you send an email to "support" at "sourcegear.com" addressed to my attention
and include a tarball/zipfile with the information from the Support dialog (available
on the About Box). That will let me see all of your DiffMerge settings. Bring up
the dialog when you have the 2 files opened (because the dump also includes some
info on the opened files). If you want to include a copy of the 2 files, that would
be nice, but is not absolutely necessary. Then I can dig thru the dump offline and
see if there is something wrong that we haven't covered here.
thanks,
jeff hostetler
of DiffMerge included with them is feature-wise the same as the standalone 3.3.0
release. So I think we're OK as far as that is concerned and don't need to worry
about upgrading or anything. (BTW, there is a 5.0.2 or 1.0.2 available. But that
shouldn't affect the conversation here because they include the same version of
DiffMerge (albeit with a different build number).)
Could you send an email to "support" at "sourcegear.com" addressed to my attention
and include a tarball/zipfile with the information from the Support dialog (available
on the About Box). That will let me see all of your DiffMerge settings. Bring up
the dialog when you have the 2 files opened (because the dump also includes some
info on the opened files). If you want to include a copy of the 2 files, that would
be nice, but is not absolutely necessary. Then I can dig thru the dump offline and
see if there is something wrong that we haven't covered here.
thanks,
jeff hostetler
Re: Hide Unimportant Differences bug?
Thanks Jeff. Hopefully this is just user error.
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
To follow up publicly, after looking at Cat's data files and configuration information,
I found that there is a problem with the Hide Unimportant feature.
The (shall we say obscure) problem happens because the comment line prior to the "return"
statement ended with "//" and the EOL. The comment-starter/EOL combination causes
DiffMerge to think we are still in "comment" context at the start of the next line. If there
are any characters following the "//" and before the EOL, the problem does not happen.
To make matters somewhat worse, when in this state there can be one or more blank
lines between the comment line and the return statement and the problem still happens.
I'll have a fix for this in 3.4 (but I don't have a date for that yet).
jeff
15167
I found that there is a problem with the Hide Unimportant feature.
The (shall we say obscure) problem happens because the comment line prior to the "return"
statement ended with "//" and the EOL. The comment-starter/EOL combination causes
DiffMerge to think we are still in "comment" context at the start of the next line. If there
are any characters following the "//" and before the EOL, the problem does not happen.
To make matters somewhat worse, when in this state there can be one or more blank
lines between the comment line and the return statement and the problem still happens.
I'll have a fix for this in 3.4 (but I don't have a date for that yet).
jeff
15167
Re: Hide Unimportant Differences bug?
Hi,
i've encountered a similar problem.
when commenting-out a block (c-style) only the opening of the comment is marked as important change.
attached a test case.
maybe it's the same root cause.
thanks,
eliad.
i've encountered a similar problem.
when commenting-out a block (c-style) only the opening of the comment is marked as important change.
attached a test case.
maybe it's the same root cause.
thanks,
eliad.
- Attachments
-
- example
- comment_bug.png (43.66 KiB) Viewed 19418 times
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
That's actually a slightly different issue. The beginning of the "/*" is treated
as a main-line context so that it'll stand out when it appears opposite regular,
main-line context. We then treat the changes following the "/*" as unimportant.
For example, if we had
abc = def + ghi;
vs
abc = def /* + ghi */;
I'd want to see the initial "/*" highlighted because there was a significant
change in the line. Whereas if it was
abc = def /* + ghi */;
vs
abc = def /* + ghi + jkl */;
I wouldn't care that the contents of the comment had changed.
jeff
as a main-line context so that it'll stand out when it appears opposite regular,
main-line context. We then treat the changes following the "/*" as unimportant.
For example, if we had
abc = def + ghi;
vs
abc = def /* + ghi */;
I'd want to see the initial "/*" highlighted because there was a significant
change in the line. Whereas if it was
abc = def /* + ghi */;
vs
abc = def /* + ghi + jkl */;
I wouldn't care that the contents of the comment had changed.
jeff
-
- Posts: 1
- Joined: Wed Mar 24, 2010 6:31 am
Re: Hide Unimportant Differences bug?
Having recently been bitten by this nasty comment bug, I don't want to suffer it again. If 3.4 isn't imminent, could a version of 3.3.0 with just this fix be released?
Paul.
Paul.
-
- Posts: 534
- Joined: Tue Jun 05, 2007 11:37 am
- Location: SourceGear
- Contact:
Re: Hide Unimportant Differences bug?
sorry, i understand the frustration.
i currently don't have a release date
set for 3.4. i'll have to check on maybe
doing a 3.3.1 with this, but I don't think
it would be until later in the summer at
the earliest.
sorry.
jeff
i currently don't have a release date
set for 3.4. i'll have to check on maybe
doing a 3.3.1 with this, but I don't think
it would be until later in the summer at
the earliest.
sorry.
jeff