Maury Markowitz wrote:
>>Did you try the -b / -B or other options to cvs diff?
>>
>>
>
>I don't think I explained myself very well. The problem isn't that it
>marked whitespace as a change; as others have noted, a change is a
>change.
>
>The problem was that given a single minor whitespace change, and
>*nothing else*, it would mark off huge passages of the contents as
>changed.
>
>For instance, the GUI editor would automatically remove a leading tab on
>a blank line when you saved the file. When later doing my checkins, CVS
>would correctly add the file as a new revision.
>
>Then at some later time I'd try to examine my changes, and CVS (via
>diff) would claim that I had actually changed some 50% of the text,
>comprising a huge number of minor one and two-line changes.
>
>So CVS was doing the right thing in storing the file as a result of a
>change. However the information I was able to extract from it was
>essentially useless. I never found a way to tell CVS to consider all
>changes to leading whitespace as "no change", nor was I able to
>understand why single changes would result in this huge change lists.
>
>
>
>>Subversion uses an internal diff library.
>>
>>
>
>I guess I would have to use it to know for sure, but does vdelta avoid
>the problems I saw with diff?
>
>
vdelta is something else entirely. Our internal diff (which gets used by
default by "svn diff") is IIRC based on the same algorithm as used by
GNU diff. I don't _think_ you should be seeing that kind of problem.
However, it's always possivble that your editor, e.g., removed one tab
and changed all the end-of-line markers (say, from \n to \r\n).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 21:13:38 2005