[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-18 14:30:00 CET

Pete Gonzalez wrote:
> Ben Collins-Sussman wrote:
>
>> On the other hand, there are much, much simpler ways to accomplish
>> this. Just attach an svn:mime-type property to all your .resx files
>> which is something non-texty (i.e. not text/*). The diff engine will
>> automatically skip over any file that the client thinks isn't text.
>
> The actual subset is more complicated than just "*.resx", and since this
> repository contains thousands of files, I think it would be impractical
> to expect people to manually set these properties for individual files.

You (one user or administrator) can set all the existing ones at once, and then
use "auto-props" to make sure that new files get the property as well. (Read
about "auto-props" in the book or ask on the "users@" email list.)

> 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 ...

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'm not sure whether that was per diffed file or for the whole
diff output, but such a script might be the best place in which to implement
such a feature, not needing to be compiled in to Subversion itself.

We are grateful to you for wanting to contribute your patch to the software.
To explain why the emphasis of these replies is on using the existing features:
before we can incorporate any new feature we need to discuss the design
rationale for the feature: why it does what it does, why it doesn't do other
things, etc., to be sure that it is a logically complete feature that fits in
well with the rest of the system.

If, after trying the properties approach and/or the mailer script approach, you
feel it doesn't solve your problem well, then please discuss it here so we can
determine whether some enhancement or bug fix to the existing features would
help or whether you still need something more like this patch provides. Of
course if there is a clear need for something like this then we (including you)
can go ahead with designing and implementing it.

> Also, IIRC the "svn:mime-type"
> property affects all diffs, but in most interactive contexts people
> would want to see differences.

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. Maybe
there are a few files for which they might occasionally want to do so, but
surely not most files most often.

(I will admit that there is a design flaw in our "external diff" design whereby
it is currenly impossible to get any diff of a file that has a MIME type
property that Subversion thinks is "binary". Fixing that would overcome this
particular point.)

> The idea of using properties makes sense, but maybe if a directory
> property recursively applied to its contents. Can you think of any
> other simpler solutions?

That might be handy, depending on what it did exactly, but the "auto-props"
feature should work well enough for the time being. Let us know right away if
it doesn't.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 18 14:31:21 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.