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