Sorry Noorul, but -1 on adding more UI complexity without better
justification.
- Julian
On Wed, 2011-07-20 at 16:47 +0530, Noorul Islam K M wrote:
> Julian Foad <julian.foad_at_wandisco.com> writes:
>
> > Noorul Islam K M wrote:
> >
> >> From issue tracker:
> >> ==================================================================================
> >> Add an option to ignore files with only property changes and no content changes.
> >> e.g. svn log --ignore-properties
> >>
> >> Motivation: many users are not interested in reviewing changes to property changes
> >> and only care about content changes.
> >> ==================================================================================
> >
> > Hi Noorul. This issue is not ready to be implemented, it is just a
> > vague idea. It needs high-level design: what is the basic idea (in more
> > detail), and what exact functionality is wanted, in terms of all the
> > things 'log' can do? The following points need to be considered, at
> > least:
> >
> > * The basic idea comes from a motivation that is stated as, "Many
> > users are not interested in reviewing changes to property changes
> > and only care about content changes." What functionality would best
> > satisfy that goal? To hide all the property changes, or to hide
> > revisions that contain only property changes, or to hide revision in
> > which the specified target contained only property changes, or something
> > else?
>
> I think the patch satisfies the goal. Do we already has an option to
> achieve the goal; get me the logs of revisions that has some text
> change.
>
> >
> > * Should we be able to specify which props to ignore?
> >
> > * When a sub-tree target is specified, does the 'props only' test
> > apply just within the specified subtree or within the whole commit?
> >
> > * Should we display the basic commit info at all if there are no
> > non-prop changes?
> >
> > * How should it affect the list of files displayed by '--verbose'?
> >
> > * How should it affect the '--diff' display? When this shows a diff
> > of file content, should it also show any prop changes to this file or
> > not?
> >
> > * Should we also have some kind of complementary inverse functionality
> > that shows prop changes but not file content changes, or something like
> > that?
> >
> > * What about directories - should a directory be treated like a file
> > with no content, for the purposes of this design, or in some other way?
> >
>
> Can this patch be a starting point? If we really don't want these
> options to be allowed with some other options then we can restrict the
> user from doing so.
>
> >
> > And, importantly, is this really a problem that needs solving? Do you
> > think it's important? Can you come up with some use case examples that
> > demonstrate why it's important and how a proposed solution would help?
> >
>
> I feel that it will be useful to filter out revisions that has only
> property changes from log output. Most of the time I felt the same.
>
> >
> >> Attached is the patch which adds two new options to "svn log" command.
> >>
> >> 1) --ignore-props-only
> >>
> >> If passed log will ignore revisions that has only property changes.
> >>
> >> 2) --props-only
> >>
> >> If passed log will retrieve revisions that has only property changes.
> >>
> >> This time, I implemented with the help of a receiver. Please let me know
> >> your comments and suggestions regarding this patch.
> >
> > What parts of the problem does your patch solve and what parts doesn't
> > it solve? (That's a genuine question; I can't see from your patch what
> > your new options do, exactly.)
> >
>
> The patch I submitted ignores the revisions that has property changes
> alone and vice versa. It doesn't matter how many extra options we pass.
Received on 2011-07-20 14:58:25 CEST