Eugene Kuleshov <eu@md.pp.ru> wrote on 12/05/2005 02:42:58 PM:
> > I do not think this makes sense for something like our SVN
> > Properties view which is meant to be an interface for editing
> > properties.
>
> That is exactly the purpose of properties view. You can plug in
> your own editors or let user edit properties in place. You can even
> provide your own custom panel it you want to (see properties handling
> in WTP's XML Schema editor).
It is not the editing part that I was talking about, I meant that the
content of the view changes whenever you click on something.
> I don't see why not, if you do that asynchronously in a background
> job and cache results locally (and clean cache on refresh).
> That would be much better then looking at frozen workbench window
> for 30 seconds while properties dialog is waiting for server response.
> Even if you won't go with Properties view it would make sense to use
> your own SVN Properties view for this.
It isn't going to happen (from me). I did not use the SVN Properties view
because showing the properties was just a throw-in feature. The purpose
of the dialog is to show the svn info output, specifically any lock
information if the file is currently locked.
> Arguably. You could still pigy back to special section im
> properties view focused on revision selected in a history view.
The other suggestions are all valid and just a toss-up choice which way to
go. This one I just do not agree with. I think this deserves a special
option.
> It is just look ugly when properties with similar name/prefix are
> shuffled randomly in the list (even with 10 properties like in
> subclipse's own repository).
I do not think I have ever seen anything with more than 4, but if it
bothers you I have no problem adding sorting.
> > 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.
>
> Hmm. I thought if you could rename/move resources you might as well
> change properties implicitly creating new revision...
This is historical information. When you restructure a repository the
changes are only in the current revision. So the record of the copy needs
to reflect what it was at the time the copy was made. This isn't that big
of a deal, it just complicates the API usage when referring to an item. We
would need to use an API that accepts the "peg revision" syntax and
currently not all of the API's we use offer it. Most notably svn log.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Dec 6 08:04:02 2005