Hans-Emil Skogh wrote:
>>> - Add property-status column.
>> there is no _real_ status for separate properties.
>> Subversion only knows a property status for *all*
>> properties of an item. Sure, we could create our
>> own status for this (modified, unchanged,
>> added, deleted).
>
> I imagine that would be valuable for people who are working a lot with
> properties. Sounds like a good idea to me to implement it somewhere at
> least.
Sounds good, but maybe a lot of work?
>> But then the questions are:
>> * should we show deleted properties in that dialog?
>
> ...probably yes. Hmm... Maybe shown in a red color? - Ok. I'm starting
> to get a bad feeling about this. We will be mixing an edit-dialog with
> and status-dialog.
> When editing I would assume that deleting a property would make it go
> away. When checking the status I would expect deleted properties to be
> in the list.
> Bad idea to try to fit them both under one hat.
>
>> * if yes, what should we do if the user tries to edit a deleted
> property?
>
> Generally I would suggest to only allowing the revert-operation on a
> deleted property.
I think this is manageable. Maybe use the Added/Modified/Deleted icons
in the new column. Deleted properties could be shown greyed and cannot
be edited.
If we (who's we? I mean Stefan) do this then maybe there should be a
per-property revert for all of these too.
>
>>> Keep it as similar to the commit/check for
>>> modifications-dialogs as possible.
>> Agreed. But then again: why do the same in the
>> properties dialog if we already have the
>> check-for-modifications dialog?
>
> The check-for-modifications dialog does not have the precision. There
> you can only see if any of the properties has changed, not which one(s),
> and only diff all property changes at once.
>
> Maybe we should add yet another dialog;
> check-for-modifications-properties? Or better yet expand the current
> check-for-modifications dialog with a list showing the modified
> properties of the currently selected item?
>
> That could work: Having the check-for-modifications dialog with a
> property list (including a property status column) below the file list,
> just as the commit dialog has the log text-box above. When selecting a
> file in the list, the properties would be loaded (including deleted
> ones) allowing for fine-grained diff and revert.
> That would give added value to the check-for-modifications dialog, while
> keeping the properties dialog un-confused.
That sounds more confusing to me. You can already access the standard
property dialog from within check-for-modifications, and it seems
Not-Too-Scary(TM) to add diff functionality to that.
But I think the property dialog should show only the current value and
not attempt to show old and new in columns. As Stefan says, multi-line
properties will not show up well, so using Tmerge sounds as good a way
as any for diffing properties.
I am not too sure what happens if there are remote property changes. We
can diff remote file changes, so in theory we should do the same for
props. In practice, does anyone really want to do this?
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Aug 4 00:35:01 2006