[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: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Sat, 10 Jan 2015 16:40:28 +0100

On 10.01.2015 15:53, cpengr wrote:
>> > Re - "BUG 2":
>> As of svn 1.8, *all* properties are inherited. But inheritance does not
>> change the functionality, that's why svn:ignore does not ignore the
>> values it inherits, only those that are set directly.
>> TSVN's rationale is that it shows what's actually happening with the
>> properties (it's the properties dialog after all). To configure the
>> ignore stuff, you have separate TSVN commands.
> 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.

> And for TSVN, I'd rather have it reflect actual resulting behavior, not
> the behavior of some implementation quirk. Isn't that the part of the
> point of a GUI?

For ignore specific UIs, yes. But the property dialog is there to manage
properties alone. And therefore that UI has to follow the rules of
properties, not their corresponding features.

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

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


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest interface to (Sub)version control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-01-10 16:40:30 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.