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?
Cheers,
-Pete
---------------------------------------------------------------------
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