[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn properties display bugs

From: cpengr <cp.engr0_at_gmail.com>
Date: Sun, 11 Jan 2015 12:24:30 -0500

> >> > 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

> >> But with multiple inherited
> >> props and the directly set prop shown at the same time, you could end
> >> 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?



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-01-11 18:24:37 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.