Ping...
Has any of the committers had a chance to review Pete's patch? If
nothing happens with it in the next few days, I'll add it to the issue
tracker.
-Hyrum
Pete Gonzalez wrote:
> Hyrum K. Wright wrote:
>> Thanks for the patch! Although I haven't had a chance to review it, I
>> do have a couple of suggestions. First, your patch stands a much better
>> chance of getting some attention from a reviewer if you include a log
>> message along with it. See the relevant portions of HACKING[1] for more
>> details.
>
> [[[
> Added a new option "--no-diff" to the "svnlook diff" subcommand
>
> * subversion/subversion/svnlook/main.c
> (print_diff_tree, do_diff): Added no_diff_patterns parameter.
> (get_ctxt_baton): Added no_diff member to svnlook_ctxt_t.
> ]]]
>
> And here are some more detailed notes:
>
> This patch adds a new option --no-diff to the "svnlook diff"
> subcommand. This new option excludes filenames that match a list of
> regular expressions. It is similar to the options --no-diff-deleted and
> --no-diff-added which exclude newly added/deleted files.
>
> For example, if you wanted to generate a report of the changes in
> revision 1234, but wanted to exclude Visual Studio machine generated
> files, you might type something like this:
>
> svnlook diff the_repository -r 1234 \
> --no-diff "*.resx *.Designer.cs *.csproj *.vcproj *.sln"
>
>> Second, when referring to previous threads on the list, it is much
>> easier for the readers if you just post the address to the relevant
>> message in the list archive. Most of the developers use the archive
>> here[2]. Otherwise, it may be difficult to see where the old
>> conversation ends and the new one begins, and your patch may get lost in
>> the noise.
>
> For reference, here is the original thread:
> http://svn.haxx.se/dev/archive-2005-11/0994.shtml
>
> Karl Fogel wrote:
>> Are there any arguments for 'svnlook diff --no-diff "..."' that
>> wouldn't also apply to 'svn diff --no-diff "..."' ? (In other words,
>> wouldn't we patch both?)
>
> This suggestion makes sense to me, and I would be willing to be the
> person who implements it if the other patch is accepted. However, I
> should note that personally I would rarely choose to filter "svn diff",
> and if I did the rules would be somewhat different.
>
>> Further thoughts: would an 'svn:no-diff' property do this better, so
>> people wouldn't have to construct the option's parameter all the time?
>> A --force flag could override it. Perhaps it could co-exist with the
>> --no-diff option.
>
> In my case, svnlook is being run from a shell script that supplies the
> options. The shell script is interested in different things than an
> ordinary person doing their daily work, and I would find it awkward to
> modify the entire repository database to accommodate one shell script.
> :-) However, I can see how the "svn:no-diff" attribute might be useful
> to an administrator who wants to provide system-wide defaults,
> especially if the upcoming "Repository-defined autoprops" feature were
> available.
>
>> Yes, I'm engaging in rampant speculation here. But I'd like us to
>> identify the problem and think about all ways to solve it. Often a
>> first patch turns out to be a subset of what's really called for.
>
> No problem -- I'm open to any other suggestions or feedback.
>
> Cheers,
> -Pete
>
Received on Tue May 8 16:35:36 2007