Eugene Kuleshov <firstname.lastname@example.org> wrote on 12/05/2005 12:04:06 PM:
> Any reasons why? Those all properties. Well, different kinds, but
> properties. So, put them under different sections in Properties view.
Just because of the way that view works. As you click on different
things, the contents of the view changes based on your selection. I do
not think this makes sense for something like our SVN Properties view
which is meant to be an interface for editing properties.
It doesn't make sense for the remote information because we would never
populate this information automatically as it is too expensive to
It doesn't make sense at all for the commit properties as that is
essentially running a "commit-type" operation against the remote
> Again why not? With Properties view user will have more responsible
> kick properties action from the repository view and properties view will
> populated asynchronously. I believe it would make much sense to do it
> way, then fix all the usability issues with repository properties
> such as sorting properties by name, making dialog resizeable,
> property values, etc.
I do not think there are usability issues with these items. Do you work
with a lot of repositories that have so many properties on items that you
would need to sort them? If so, we can add sorting support easily enough.
Also, it isn't possible to modify versioned properties in the repository,
so those options will never be made available.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Tue Dec 6 04:45:29 2005