Pete Gonzalez wrote:
> 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"?
Yes. There's a lot of truth in what you say in this email.
> 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.
One of the mailers that doesn't yet do it is
tools/hook-scripts/mailer/mailer.py. On about 3rd November, Alan Barrett
posted a patch to add a "truncate_diff_lines" option to it, and I believe other
mailers that support a similar thing already were mentioned by respondents to
the thread.
>>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.
Well, all right. (I suppose I don't know what it's like working with such files.)
[...]
> 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?
Again, you're on to a reasonable argument. Perhaps you would like to make a
more general post with a proposal to get the community to recognise this, and
come up with some sort of plan for the features and options that should be
desired? People don't like adding another little option that doesn't fit into
a plan, but if there's a plan then it's a completely different story.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 19 01:32:06 2005