Opened 19 years ago
Closed 19 years ago
#1896 closed defect (fixed)
hide svk:merge and other human unreadable properties in the source browser and changeset view
Reported by: | Jonas Borgström | Owned by: | Christian Boos |
---|---|---|---|
Priority: | normal | Milestone: | 0.9 |
Component: | version control/browser | Version: | devel |
Severity: | normal | Keywords: | svn property |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Attachments (1)
Change History (11)
comment:1 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 19 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
IMO this "fix" is invalid. Hiding certain properties is more confusing than displaying those that aren't "human readable". It is impractical and confusing for Trac to keep a list of non-human-readable properties and explicitly filter them out. Trac should simply display what is in the repository.
comment:3 by , 19 years ago
IMHO, this kind of filter is handy, because users as myself really don't want to bother with the internal keys of the repository back end, as they provide no more info than noise.
However, I agree on one point: it's impractical for Trac to keep a list of such properties, and I think a more 'natural' location for this definition would be in the INI project file, so that admins can select which properties they wish to hide, if any.
comment:4 by , 19 years ago
Keywords: | svn property added |
---|---|
Owner: | changed from | to
Status: | reopened → new |
Type: | defect → enhancement |
I agree with Mark, I think the svk:merge
should not be arbitrarily hidden.
I think a solution similar to the one I suggested for #1601 could be used here.
A generic HiddenPropertyRenderer
could be selected in the trac.ini
for the
non-human-readable properties, and this would be more flexible than being
hard-coded in the source.
OTOH, a specific SvkPropertyRenderer
can be written to display
the svk:merge
property in a more pleasant way.
comment:5 by , 19 years ago
How about just making this configurable as eblot suggested, for example:
[browser] hide_properties = svk:merge, svn:eol-style
This should affect both the browser and the changeset view.
I don't think we should have components for displaying properties, at least not at this point. We really want to finish up 0.9 for a beta release, so a simple fix is the only thing that'll have a real chance to get in.
comment:6 by , 19 years ago
Can the properties section be made to fold/unfold on page? If there's a property, readable or not, some would want to see it, say, when troubleshooting things.
comment:7 by , 19 years ago
fold/unfold sounds like Javascript. There have already been a couple of ML theads about this topic 8)
Or, the page could have a 'property' HTML division to select which properties should be shown, something similar to the options available for the timeline: I share the opinion of cmlenz: make something simple enough so that it can integrate into 0.9 release, and postpone a more flexible solution for 1.0 or later.
by , 19 years ago
Attachment: | browser_hide_properties.diff added |
---|
Configurable list of hidden properties
comment:8 by , 19 years ago
Milestone: | 0.9 → 1.0 |
---|---|
Status: | new → assigned |
Type: | enhancement → defect |
Ok, let's post-pone the custom property renderers, and in the meantime implement cmlenz's suggestion.
Would attachment:browser_hide_properties.diff be OK?
comment:9 by , 19 years ago
Milestone: | 1.0 → 0.9 |
---|
The patch looks good.
I think after it has been applied, we should close this ticket. #1601 covers the property renderers, no?
comment:10 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed in [2075].