[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] "svnlook diff" option to filter files

From: Pete Gonzalez <pgonzalez_at_bluel.com>
Date: 2005-11-18 20:39:48 CET

Julian Foad wrote:
>> It makes more sense to have a global wildcard that can be updated from
>> time to time when new problems appear.
> I can certainly see that that would do what you want today, nicely.
> The thing is, it doesn't seem like a general enough solution to
> include in the product. Tomorrow you will find (or the next
> person who tries to use it will find) that a filename wildcard
> isn't enough, and it needs to distinguish between files in
> different directories, or between short (hand-written)
> files and long (machine-generated) ones of the same type, or ...

I agree that there are probably more flexible interfaces than
my special-purpose filter. However, couldn't a similar argument
be made regarding "--no-diff-added" and "--no-diff-deleted"?
So far I haven't seen any clear design goals for svnlook other
than "almost no options at all". For example, try typing
"man diff" some time. :-)

Internally, svnlook's "diff" subcommand performs a number of
steps such as:

- Build a list of all changed paths, classified as "added",
  "modified", or "deleted"
- Determine which ones are binary files
- Discard some of them according to "--no-diff-deleted" etc
- Detect property changes
- Collect everything into a formatted report, executing the Unix
  diff command on each changed file

Trying to duplicate that functionality in a bash script (e.g. if
the "diff" subcommand didn't exist) would be quite complex. That's
why I think the svnlook algorithm should be more configurable.

Regarding the particular interface, I don't have strong opinions as
long as it's simple to use.

> Hmm... Talking of short and long, have you looked at the commit
> mailer hook scripts available? At least one of them has support
> for suppressing diffs that are longer than a certain length. This
> was discussed recently on the "dev@" list, as somebody was wanting
> to put a similar feature into one of the other mailer scripts.

I would like to see such a script if it really exists. I originally
tried to solve this problem in the hook script (which is arguably
where hacky heuristics belong). As far as I can tell, the only
way would be to generate the full diff output and then parse
it (e.g. with a Perl script). I chose to modify svnlook because I
thought it would be less typing and more clean.

> Do you really believe that people would normally want to see the
> differences in those "*.resx" files that you mentioned when
> they use "svn diff", but would not want to see them in the
> commit email? That sounds implausible to me.

During development, it's very important to be able to compare exactly
what has changed in every single text file. Before committing my
work, I always review every single diff of every single text file.
You can catch a lot of errors this way, as well as a lot of spurious
edits that can be safely removed. With .resx files it's particularly
important because spurious edits are responsible for a lot of
spurious Subversion conflicts. (Also, I must confess that I
use TortoiseSVN, so the extra clutter is trivial to navigate.)

By contrast, in the hook e-mail you just want to see what people
are really working on. Huge diff blocks for machine generated
files make these e-mails nearly useless. It's a big enough
nuisance that I invested time trying to make the e-mails as
concise as possible. I say all this as an argument that
svn:mime-type affects too many other systems, when all I wanted
to do was customize a simple e-mail.

More to the point: Subversion is a tool for managing file diffs.
So why is it strange to expect lots of options for customizing
the report of what files were changed?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 18 20:41:06 2005

This is an archived mail posted to the Subversion Dev mailing list.