Is that not what I'm doing by setting svn:auto-props to *= on the child node?
On Thu, Dec 9, 2021 at 10:46 AM Justin MASSIOT | Zentek < justin.mass...@zentek.fr> wrote: > By overcharge I meant "define a new property with a value which differs > from the one that is inherited", either for svn:auto-props or > svn:needs-lock. > I'm really not sure it would work, but it's worth the try. > > Justin MASSIOT | Zentek > > > On Thu, 9 Dec 2021 at 10:43, Sebastian Weilhammer < > sebastian.weilham...@madheadgames.com> wrote: > >> Hello Justin, >> >> So that's the thing, I cannot seem to remove the svn:needs-lock from >> svn:auto-props for the node in question and I can't change it's value in >> such a way where it will stop adding svn:needs-lock to newly added files. >> If that's what you mean by overcharge? >> >> Essentially setting svn:auto-props to *=, *=svn:needs-lock= or >> *=svn:needs-lock does not get this to work. >> >> On Thu, Dec 9, 2021 at 9:18 AM Justin MASSIOT | Zentek < >> justin.mass...@zentek.fr> wrote: >> >>> Hi Sebastian, >>> >>> As far as I've understood, since Subversion 1.8 the property >>> "svn:auto-props" is automatically inherited. >>> Have you tried to overcharge the property at the node you want >>> a variation? Not sure but it might take precedence... >>> >>> Justin MASSIOT | Zentek >>> >>> >>> On Wed, 8 Dec 2021 at 23:30, Sebastian Weilhammer < >>> sebastian.weilham...@madheadgames.com> wrote: >>> >>>> Hello, >>>> >>>> I'm having trouble with these features. >>>> >>>> I have a folder on which I have set svn:auto-props to >>>> *=svn:needs-lock=*. >>>> I have another folder within this folder for which I would like >>>> anything inside to not require locks. >>>> >>>> It seems, I have no way of removing auto setting the needs lock >>>> property on newly added files? >>>> >>>> This makes sense I guess, considering svn:needs-lock doesn't require a >>>> value, just needs to be set. >>>> Feels like the needs-lock requiring either 0 or 1 as a value would make >>>> this customizable? >>>> >>>> Am I correct in my assumption? Or is there a way of handling this >>>> specific scenario gracefully? >>>> >>>> Best, >>>> >>>> Sebastian >>>> >>>> >>>> >>> >> >> -- >> >> *Sebastian Weilhammer* >> >> Technical Director >> >> madheadgames.com <http://www.madheadgames.com/> >> >> <https://www.facebook.com/madheadgames> >> <https://www.instagram.com/madheadgames/> >> <https://www.linkedin.com/company/mad-head-games> >> <https://twitter.com/madheadgames> >> > -- *Sebastian Weilhammer* Technical Director madheadgames.com <http://www.madheadgames.com/> <https://www.facebook.com/madheadgames> <https://www.instagram.com/madheadgames/> <https://www.linkedin.com/company/mad-head-games> <https://twitter.com/madheadgames>