Den tors 9 dec. 2021 kl 11:18 skrev Sebastian Weilhammer <
sebastian.weilham...@madheadgames.com>:
> Is that not what I'm doing by setting svn:auto-props to *= on the child
> node?
>
I have tried the following, I think this is matches what you are trying to
do. This is done using Subversion 1.14.
Not if the needs-lock attribute is also set by a "svn:auto-props" property,
I suppose.
Justin MASSIOT | Zentek
On Thu, 9 Dec 2021 at 11:18, Sebastian Weilhammer <
sebastian.weilham...@madheadgames.com> wrote:
> Is that not what I'm doing by setting svn:auto-props to *= on the child
> node?
>
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
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
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
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, Seb
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
isn't correct since I need to prune the second ; before
it calls propset. Need to try another fix then (unless someone has fixed that
in the repo already)
/Chris
On Thu, 2/22/18, Branko Čibej wrote:
Subject: Re: auto-props syntax in file vs. pr
On 22.02.2018 13:52, Chris wrote:
> Re-awakening my previous thread about the auto-properties. I get really
> confused by where to use ;; and ; as a separator.
>
> I currently have this in the auto-props on the repo:
> *.txt = svn:mime-type=text/plain;;charset=iso-8859-1;svn:eol-s
Re-awakening my previous thread about the auto-properties. I get really
confused by where to use ;; and ; as a separator.
I currently have this in the auto-props on the repo:
*.txt = svn:mime-type=text/plain;;charset=iso-8859-1;svn:eol-style=LF
And then if I add a text file:
prompt> to
Chris wrote on Wed, 10 Jan 2018 08:26 +:
> I think the fix to svn_apply_autoprops.py should be something like below
> (/subversion/trunk/contrib/client-side/svn_apply_autoprops.py)
> If anyone with commit rights wants to fix it on the repo, feel free to
> use the below, or improve it as neces
rote:
Subject: Re: auto-props syntax in file vs. property
To: users@subversion.apache.org, "Daniel Shahaf"
Date: Wednesday, January 10, 2018, 8:25 AM
Hi Daniel,
thanks for the reply.
You're right that it seems to work when
I do "svn add" and with that c
work for double semicolons.
/Chris
On Tue, 1/9/18, Daniel Shahaf wrote:
Subject: Re: auto-props syntax in file vs. property
To: users@subversion.apache.org
Date: Tuesday, January 9, 2018, 5:05 PM
Chris wrote on Tue, 09 Jan 2018
15:15 +:
> When setting
Chris wrote on Tue, 09 Jan 2018 15:15 +:
> When setting svn:auto-props, it seems I can do this:
>
> *.java = svn:mime-type=text/java;;charset=iso-8859-1;svn:eol-style=LF
>
> That is, use ;; as an escape between the "parameters" for file type and
> charset. Adding a java-file and doing propg
these two and if there's some
common syntax that can be used for both.
If would have been nice if I could use the exact same syntax for both so I can
just paste in filetype-part of the config file into the auto-props, but it
won't kill me if I have to use separate ones, as long as I kn
> -Original Message-
> From: edward.dauver...@gmail.com
> [mailto:edward.dauver...@gmail.com] On Behalf Of Edward d'Auvergne
> Sent: dinsdag 6 oktober 2015 12:21
> To: Edward d'Auvergne ; Greg Stein
> ; users@subversion.apache.org
> Subject: Re: Bug re
On Tue, Oct 06, 2015 at 12:20:47PM +0200, Edward d'Auvergne wrote:
> So setting MAGIC is having an effect, but Subversion is falling back,
> probably via a non-magic internal code path, to the default
> svn:mime-type of "application/octet-stream" for PNG and some other
> files.
If you don't allow
oided in
FGAddon. Before committing, please remove this property by typing 'svn propdel
svn:mime-type file_name' for all affected files. Or to remove it recursively
from all files to be committed, in your aircraft directory type 'svn propdel
svn:mime-type -R'.
To avoid the sv
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
>
> > This whole discussion -in its many iterations- is one of the reasons why
I
> > never looked
On Mon, Oct 05, 2015 at 12:06:59AM +0200, Bert Huijben wrote:
> I'm not sure if I would call it a security problem when a user adds a file of
> their choosing to Subversion though :-)
Yes, typical SVN use cases are of no concern.
One case I could imagine where this might matter is some automated
On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote:
> is it really not a bug when:
>
> enable-auto-props = yes
>
> and:
>
> enable-auto-props = no
>
> both enable auto-props?
>
> Cheers,
>
> Edward
I think your best way for
On Oct 4, 2015, at 5:52 AM, Edward d'Auvergne wrote:
> So the following setting disables [auto-props]:
>
> enable-auto-props = no
>
> If a svn:mime-type was defined in the config file, this is now
> disabled. However in this case, [magic-auto-props] then decides t
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zondag 4 oktober 2015 22:01
> To: Branko Čibej
> Cc: users@subversion.apache.org
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
>
> On Sun,
On Sun, Oct 04, 2015 at 09:16:04PM +0200, Branko Čibej wrote:
> On the other hand, I am surprised that the logic that uses libmagic
> isn't turned off with 'enable-auto-props=no'. After all, using libmagic
> is just a convenient extension to the definitions in the [auto-p
7;t. And the problem doesn't stop with 'application/xml'
because there are literally hundreds of media types for documents that
use XML.
On the other hand, I am surprised that the logic that uses libmagic
isn't turned off with 'enable-auto-props=no'. After all, using libmagic
is just a convenient extension to the definitions in the [auto-props]
section.
-- Brane
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zondag 4 oktober 2015 13:32
> To: Edward d'Auvergne
> Cc: Greg Stein ; users@subversion.apache.org
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to
On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote:
> I would maybe suggest introducing an option for disabling the entire
> automatic property subsystem, i.e. it combines both of these, and
> overrides them. This is an interesting thought experiment - devise
> any name for such a t
]On 3 October 2015 at 13:19, Stefan Sperling wrote:
> On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote:
>> is it really not a bug when:
>>
>> enable-auto-props = yes
>>
>> and:
>>
>> enable-auto-props = no
>>
>
by the xml inventers was a safe decision.
Your files are just not 'generic xml', and should have a more specific type.
Bert
From: Ivan Zhakov
Sent: zondag 4 oktober 2015 11:35
To: Edward d'Auvergne
Cc: users@subversion.apache.org
Subject: Re: Bug report: The auto-props se
On 2 October 2015 at 11:06, Edward d'Auvergne wrote:
> Hi all,
>
> I was wondering if this should be considered a bug. At the FlightGear
> project we have a 6 GB data svn repository for aircraft (
> https://sourceforge.net/projects/flightgear/ ,
> https://sourceforge.net/p/flightgear/fgaddon/HEAD
On Sat, Oct 3, 2015 at 6:53 AM, Ryan Schmidt
wrote:
>
> On Oct 3, 2015, at 4:13 AM, Edward d'Auvergne wrote:
>
>> is it really not a bug when:
>>
>>enable-auto-props = yes
>>
>> and:
>>
>>enable-auto-props = no
>>
>> bot
On Oct 3, 2015, at 4:13 AM, Edward d'Auvergne wrote:
> is it really not a bug when:
>
> enable-auto-props = yes
>
> and:
>
>enable-auto-props = no
>
> both enable auto-props?
Obviously, "enable-auto-props = yes" should enable auto-props an
On Oct 3, 2015, at 3:25 AM, Edward d'Auvergne wrote:
> On 2 October 2015 at 11:33, Stefan Sperling wrote:
>
>> - configure autoprops for *.xml in ~/.subversion/config to set
>> the svn:mime-type property to 'text/plain'.
>> Autoprops always override automatic detection with libmagic.
>
> Fr
essentially combines "svn add *" and "svn ci" into one
without having a local checked out copy of the repository. In this
case, inserting "svn propdel" in the middle is not possible. Anyway,
is it really not a bug when:
enable-auto-props = yes
and:
enable-auto-props = no
both enable auto-props?
Cheers,
Edward
I do understand this, but this is not a "bug". It is how Subversion is
designed to work. For strange edge cases, the xml people want content to be
labeled application/xml rather than a text subtype. ... I *do* understand
that this negatively impacts your development workflow.
Note that you can alw
On 3 October 2015 at 01:05, Greg Stein wrote:
> On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
>>...
>> As this bad behaviour can be so incredibly damaging for this
>> repository,
>
> Note: the files themselves are not "damaged" -- Subversion will never
> alter the contents of
The current policy is that the svn:mime-type property is to be avoided in
FGAddon. Before committing, please remove this property by typing 'svn propdel
svn:mime-type file_name' for all affected files. Or to remove it recursively
from all files to be committed, in your aircraft direct
as "application/xml". Hence they
>> are treated as binary files! There are many other text files with
>> extensions such as *.ac, *.nas, etc. present in the repository that in
>> the future might be detected by libmagic as "application/xyz".
>>
>> We h
On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
>...
> As this bad behaviour can be so incredibly damaging for this
> repository,
Note: the files themselves are not "damaged" -- Subversion will never
alter the contents of a file when it is first imported/added. It may
make a fil
"Edward d'Auvergne" writes:
> I was wondering if there was anything that has been missed here? Is
> this a real bug? The svn:mime-type property is not needed and is not
> desired for any file in this repository. Any help would be
> appreciated.
You can disable libmagic by setting the environm
xtensions such as *.ac, *.nas, etc. present in the repository that in
> the future might be detected by libmagic as "application/xyz".
>
> We have looked at disabling [auto-props] both as the user in
> ~/.subversion/config and as root in /etc/subversion/config by setting:
>
detects all these XML files as "application/xml". Hence they
are treated as binary files! There are many other text files with
extensions such as *.ac, *.nas, etc. present in the repository that in
the future might be detected by libmagic as "application/xyz".
We have looked at d
the
>> bindings which I suspect would be quicker... I'll have a go at
>> installing those and reimplementing it, the experience might be useful
>> elsewhere.
>
> What script are you talking about? I cannot find a script called
> 'svnprops.py' anywhere wi
perience might be useful
> elsewhere.
What script are you talking about? I cannot find a script called
'svnprops.py' anywhere within contrib/ or tools/.
You are talking about applying auto-props, so maybe this script can help you?
https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_apply_autoprops.py
On Fri, Oct 14, 2011 at 7:35 AM, Ryan Schmidt
wrote:
>
> On Oct 12, 2011, at 16:35, Talden wrote:
>
>> Is anyone aware of an alternative to svnprops.py (or an updated
>> version) that works with Subversion 1.7 (and on Windows)?
>
> svnprops.py doesn't work with 1.7? What happens?
The version I ha
On Oct 12, 2011, at 16:35, Talden wrote:
> Is anyone aware of an alternative to svnprops.py (or an updated
> version) that works with Subversion 1.7 (and on Windows)?
svnprops.py doesn't work with 1.7? What happens?
Is anyone aware of an alternative to svnprops.py (or an updated
version) that works with Subversion 1.7 (and on Windows)?
If not I'll get my hands dirty but python-fu is weak and it'd be great
not to have to reinvent the wheel unnecessarily.
--
Talden
Thanks for your answer. Now I understand my mistake ;)
W dniu 2010-12-29 20:50, David Weintraub pisze:
On Wed, Dec 29, 2010 at 12:01 PM, Leszek Porębski
wrote:
Hi!
I have the Revision auto-property set on files. It works pretty fine until
you copy a file (etc. by branching it's project). Aft
On Wed, Dec 29, 2010 at 12:01 PM, Leszek Porębski
wrote:
> Hi!
>
> I have the Revision auto-property set on files. It works pretty fine until
> you copy a file (etc. by branching it's project). After this adding $Rev$ to
> its content has no effect.
Did the original file have that property on it?
o Subversion's MIME type auto-detection
### algorithm.
# mime-types-file = /path/to/mime.types
### Set preserved-conflict-file-exts to a whitespace-delimited
### list of patterns matching file extensions which should be
### preserved in generated conflict file names. By default,
### conflict
ops.
And apart from that, there's the unavoidable problem that the client's
working copy is immediately out-of-date after he commits (because of
the additional commit from the post-commit hook).
The usual approach is:
- Create a standard client-side config file with the correct
auto-props setti
2010/9/10 Vojáček Aleš :
> Hi all,
> Is it possible to set up enable-auto-props = yes and eon styles on server
> side, or this is possible only on client side?
>
> I want to set up this on server side, because I do not want to change configs
> on all clients and I want to
Hi all,
Is it possible to set up enable-auto-props = yes and eon styles on server side,
or this is possible only on client side?
I want to set up this on server side, because I do not want to change configs
on all clients and I want to be sure, that all clients will set up autoprops
correctly
>
> Hi Justin,
>
> On Fri, Jun 25, 2010 at 09:09:39AM -0500, Justin Johnson wrote:
>
> > I am attempting to import a file and set svn:eol-style in one command
> using
> > the --auto-props and --config-option options to svn import. When I do
> the
> > impor
Hi Justin,
On Fri, Jun 25, 2010 at 09:09:39AM -0500, Justin Johnson wrote:
> I am attempting to import a file and set svn:eol-style in one command using
> the --auto-props and --config-option options to svn import. When I do the
> import I explicitly specify the file name in the i
>
> Hi,
>
> I am attempting to import a file and set svn:eol-style in one command using
> the --auto-props and --config-option options to svn import. When I do the
> import I explicitly specify the file name in the import URL. The reason I
> do this is because I want to i
Hi,
I am attempting to import a file and set svn:eol-style in one command using
the --auto-props and --config-option options to svn import. When I do the
import I explicitly specify the file name in the import URL. The reason I
do this is because I want to import from a randomly generated temp
Ravi Roy wrote:
>Just curious if there is a way out to set auto-props for certain binary
>files on server side ? I know, it is can be set on Client like TortoiseSVN.
auto-props are a client side configuration that's shared by all
subversion clients (TSVN only provides a GUI for that t
On Mon, Jun 7, 2010 at 12:01 AM, Ravi Roy wrote:
> Hi,
>
> Just curious if there is a way out to set auto-props for certain binary
> files on server side ? I know, it is can be set on Client like TortoiseSVN.
>
This feature (and similar ones) are bandied about as "reposi
Ravi Roy wrote on 06/07/2010 12:22:52 AM:
> On Mon, Jun 7, 2010 at 10:41 AM, Ryan Schmidt
> wrote:
> On Jun 7, 2010, at 00:01, Ravi Roy wrote:
>
> > Just curious if there is a way out to set auto-props for certain
> binary files on server side ?
> No, there isn't
On Mon, Jun 7, 2010 at 10:41 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:
> On Jun 7, 2010, at 00:01, Ravi Roy wrote:
>
> > Just curious if there is a way out to set auto-props for certain binary
> files on server side ?
>
> No, there isn't, not a sup
On Jun 7, 2010, at 00:01, Ravi Roy wrote:
> Just curious if there is a way out to set auto-props for certain binary files
> on server side ?
No, there isn't, not a supported way, anyway.
This has come up countless times on the mailing list before. I'm sure you can
find the di
Hi,
Just curious if there is a way out to set auto-props for certain binary
files on server side ? I know, it is can be set on Client like TortoiseSVN.
I am using Subversion 1.6.1 on CenOS 5.2 with APR 1.2.7.
Thanks.
Regards
-RR
Hi Andy
Thanks for your quick reply.
> The later. Auto-props are applied when you run svn add, so after the
> developer has added his encrypted file, he can edit the properties &
> make them right.
Actually, my previous post was incorrect - the error occurs upon add not commit:
operties on the file’s parent folder to override
> the auto-prop settings in the config file for *.v files, such that the
> eol-style will not be applied to *.v files added to that folder?
>
> Or can I set properties on the file prior to committing it, in such a way
> that the auto-pro
h that the
eol-style will not be applied to *.v files added to that folder?
Or can I set properties on the file prior to committing it, in such a way that
the auto-props will be ignored?
Best regards
David
66 matches
Mail list logo
