Re: move certain svn props to top level path?

Branko Čibej wrote:
> On 15.04.2018 23:42, Stefan wrote:
>> On 15/04/2018 22:56, Julian Foad wrote:
>>> Mark's blog post there says the spec was developed jointly with Subclipse so that's at least one other.
>>>
>>> Did you (Stefan) check inheritance works as expected?
>> I know for sure that it's working for TSVN (that's the way I set
>> things up at our company). I don't have Subclipse available however,
>> so can't check it there.

OK, that's good enough for me.

>>> - If the properties are not set for a folder, the client should search upwards
>>> in the working copy for them until the working copy root is reached.

>> I'll check with Stefan to make things either made more clear or
>> removed (if outdated meanwhile, which to me this phrase looks like) in
>> the docu.

I agree it looks like that doc is simply out of date.

>> Note that the actual user documentation is usually more
>> up-to-date and with regards to the property handling also states: "As
>> of version 1.8, TortoiseSVN and Subversion use so called |inherited
>> properties|, [...]

Perfect!

>>> If I have misunderstood something, then the Subversion feature "Inheritable properties" may possibly have made this "Just work", possibly; but I don't think so; but at least that feature should make it much easier to implement inheritance that searches up beyond the WC root to a folder that's only in the repository, if/when the various clients choose to do so.

Looks like TortoiseSVN at least was updated in that way; other clients
likely were updated too if anybody cared about them.

Good enough for me.

Please go ahead!

>>>> Tags should not change.
>>>> +1 for removing those properties from branches.
>>> That part I agree with.
>>
>> I'm not going to make a case out of this, but please be aware the
>> implications of keeping the incorrect/outdated props on the tags:

I recognize that it's an inconvenience, yes, but note the same problem
with tags exists in other forms -- e.g. there are hundreds of code
comments pointing to the old issue tracker and mailing list URLs. The
way I see it, we would not expect to modify tags to resolve those kinds
of problem, just expect the reader to beware of such issues when working
with old data, and so I feel we should apply that reasoning consistently
even though it would be technically easy to modify the data.

- Julian
Received on 2018-04-16 09:15:10 CEST