Hi Stefan,
Oops, I forgot to send it out after applying the feedback comments. Nothing to
be sorry about. Here it is, updated to apply to r1239239.
[[[
* subversion/svn/cl.h
* subversion/svn/main.c
New options, --no-diff-properties and --patch for svn diff.
* subversion/include/svn_client.h
(svn_client_diff6,svn_client_diff_peg6): New argument, ignore_prop_diff.
(svn_client_diff5,svn_client_diff_peg5): Update comments.
* subversion/libsvn_client/deprecated.c
(svn_client_diff5,svn_client_diff_peg5): Pass FALSE as ignore_prop_diff.
* subversion/libsvn_client/diff.c
(diff_cmd_baton): New field, ignore_prop_diff.
(diff_props_changed): Do nothing if diff_cmd_baton->ignore_prop_diff is set.
(svn_client_diff6,svn_client_diff_peg6): Pass ignore_prop_diff downstream
via diff_cmd_baton.
* subversion/svn/diff-cmd.c
(svn_cl__diff): Handle --patch and --no-diff-properties.
* subversion/svn/log-cmd.c
(log_entry_receiver): Request property changes from svn_client_diff6.
]]]
Regards,
Alexey.
On Wednesday, February 01, 2012 09:53:00 am Stefan Sperling wrote:
> Alexey,
>
> are you still working on this patch?
>
> Since your last submission there has been some feedback and I think
> we've reached consensus. I am sorry that our discussion flip-flopped
> a little and mislead you.
>
> I would very much like to see a version of your patch which
> incorporates the feedback you've received since your last submission.
>
> If you don't have time or interested to work on this patch anymore
> I'd like to pick it up and finish it. Else I will wait for an updated
> patch from you.
>
> Thanks!
>
> On Thu, Dec 22, 2011 at 11:18:18AM +0000, Julian Foad wrote:
> > Stefan Sperling wrote:
> > > Alexey Neyman wrote:
> > >> Stefan Sperling wrote:
> > >>> I'd prefer keeping --no-diff-properties and add a --patch option
> > >>> later which implies --no-diff-properties and maybe other options.
> > >>>
> > >> I was explicitly asked by Julian Foad to avoid adding more
> > >>
> > >> low-level options (such as --no-diff-properties) and add
> > >> "interface-level" options instead. I am fine with either approach.
> >
> > Actually, my contribution to this design discussion was only to say that
> > having a high-level option was "potentially a good direction to go
> > [...]": <http://svn.haxx.se/dev/archive-2011-11/0081.shtml>.
> >
> > > I'd prefer having both low-level and high-level options available.
> > >
> > > That way it is easier to tell what each individual option does.
> > > Higher-level options can simply explain themselves as being
> > > equivalent to some set of lower-level options.
> >
> > That sounds good to me.
> >
> > > But feel free to let us argue about it instead of getting involved
> > > in the bikeshedding. We can apply your patch as-is and change the
> > > option name later. It's no big deal. Before doing so I'll wait a bit
> > > to see what the others have to say.
> >
> > Agreed.
> >
> > - Julian
Received on 2012-02-01 21:13:45 CET