> >> > Re - "BUG 2":
> > I don't know enough about the other properties to speak to them, but
> > don't you think that at least in the case of svn:ignore, with no
> > conceivable behavioral use for inherited values, it would make more
> > sense not to inherit in the first place?
>
> As I said: as of svn 1.8, *all* properties are inherited. There is no
> distinction between properties to decide whether they're inherited or
> not, they just all are.
>
> And again: it's the feature of the property that decides whether it
> respects inherited values or only works on direct values. But the
> property is still inherited, even if the feature of the property does
> not use it.
I was making a suggestion about what I think the svn behavior ought to be,
and I was asking your opinion as a developer close to it (though realizing
you're not an svn dev, AFAIK). Telling me what the behavior *is* does not
answer the question of what it *ought* to be.
> >> > Re - "BUG 1":
> >
> >> not a bad idea, but requires a lot more work. For example, what should
> >> happen if a user tries to edit one of the inherited props?
> >
> > Probably the easiest thing would be to disable editing of inherited
> > props, i.e. the user has to navigate to the origin to edit it. (You
> > could provide a shortcut to it if you think it's important. At least the
> > path is displayed, so the user will know where it is.)
>
> That was the behavior at the beginning - users complained that it's too
> much work.
>
> >> Right now,
> >> that inherited prop is then simply set.
> >
> > Do you mean that a new prop with the same name as the inherited prop
> > (and whatever new value) is set in the current directory?
>
> Yes, but only if you edit and save it.
Is this desired behavior then, to be able to make additions/exceptions this
way?
> >> But with multiple inherited
> >> props and the directly set prop shown at the same time, you could end
up
> >> overwriting the directly set prop.
> >
> > WRT the directly-set prop, isn't that desired behavior? So long as the
> > edit box starts out with the current value of the prop, it should be
> > apparent what's happening.
>
> But it does not start with the current value but with the value of the
> inherited prop you're editing.
If this (overriding an inherited prop, and being given its current value as
a template) is a common use case, perhaps a better approach that exposes
the actual behavior is to add a new button, say "create a copy" or
something. The edit button would be disabled for inherited props, and
"create a copy" would be enabled. Regular props (edited at their source)
would have Edit enabled, and "create a copy" disabled.
What do you think?
cpengr
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3094011
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-01-11 18:24:37 CET