Stefan,
I'm still interested in your opinion on the questions I raised.
Regards,
cpengr
On Jan 11, 2015 12:24 PM, "cpengr" <cp.engr0_at_gmail.com> wrote:
> > >> > 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=3094415
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-01-17 23:26:24 CET