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.
You can change the diff program used by subversion. For instance, if you
have GNU diff installed, and are using some sort of unix, try:
* Make a script in (your home directory)/bin/diffbu containing:
#!/bin/sh
diff -bu "$@"
* chmod u+x ~/bin/diffbu
* Add to ~/.subversion/config:
[helpers]
diff-cmd = /home/user/bin/diffbu
Now all subversion commands which generate diffs will ignore
whitespace-only changes.
>>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 an internal change only, and will only be apparent in its
speedups of svn blame.
Received on Tue Feb 15 23:45:32 2005