disregarding svn:global-ignores

[Daniel Shahaf]

http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_.22Hierarchy.22
says 'svn status --no-ignore' does not disregard inherited
'svn:global-ignores' properties.

This breaks a use-case for me:
% svn status --no-ignore | xargs rm -rf

How, with a 1.8 client, would I obtain a complete list of all
unversioned files in my working copy? "Complete" means - without
excluding any files (regardless of inherited props, runtime config, etc)

[Paul Burba]

Post by Daniel Shahaf
http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_.22Hierarchy.22
says 'svn status --no-ignore' does not disregard inherited
'svn:global-ignores' properties.

Hi Daniel,

Sorry, that section is out of date, I corrected it. The --no-ignores
option still works for status, it's only for import and add that it
can't be overridden.

Post by Daniel Shahaf
% svn status --no-ignore | xargs rm -rf
How, with a 1.8 client, would I obtain a complete list of all
unversioned files in my working copy? "Complete" means - without
excluding any files (regardless of inherited props, runtime config, etc)

Here's my trunk WC (with no global-ignores set in my config):

***@1406029>svn st --depth immediates
M .
? cleanup.build.bat
? copy.svn.DEBUG.paths.bat
? copy.svn.RELEASE.paths.bat
? deleted-subtree-ranges-1.patch
? desktop.ini
? ignores
? run.RUBY.binding.tests.bat
? run.all.win-tests.DEBUG.bat
? run.all.win-tests.bat
? run.javahl.tests.bat
? run.python.test.DEBUG.bat
? run.python.test.RELEASE.bat
? sdc-reintegrate.diff
? set.svn.DEBUG.paths.bat
? set.svn.RELEASE.paths.bat
? set.up.SSD.bat
? subversion_vcnet.sln.cache
? svn-win32-Release-binaries
? svn.DEBUG.path.ONELINE.txt
? vc6-build.bat

I've set svn:global-ignores = "*.py" on the root of my WC:

***@1406029>svn diff
Index: .
===================================================================
--- . (revision 1406029)
+++ . (working copy)

Property changes on: .
___________________________________________________________________
Added: svn:global-ignores
## -0,0 +1 ##
+*.py

Note that the unversioned *.py files are revealed with the --no-ignore option:

***@1406029>svn st --depth immediates --no-ignore
M .
I Debug
I Release
? cleanup.build.bat
? copy.svn.DEBUG.paths.bat
? copy.svn.RELEASE.paths.bat
? deleted-subtree-ranges-1.patch
? desktop.ini
I find-milestone.2.py
I find-milestone.py
I gen-make.opts
? ignores
I merge_annotate_log_bug.py
? run.RUBY.binding.tests.bat
? run.all.win-tests.DEBUG.bat
? run.all.win-tests.bat
? run.javahl.tests.bat
? run.python.test.DEBUG.bat
? run.python.test.RELEASE.bat
? sdc-reintegrate.diff
? set.svn.DEBUG.paths.bat
? set.svn.RELEASE.paths.bat
? set.up.SSD.bat
I subversion_vcnet.ncb
I subversion_vcnet.sln
? subversion_vcnet.sln.cache
I subversion_vcnet.suo
? svn-win32-Release-binaries
? svn.DEBUG.path.ONELINE.txt
? vc6-build.bat

[Daniel Shahaf]

Post by Paul Burba

Post by Daniel Shahaf
http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_.22Hierarchy.22
says 'svn status --no-ignore' does not disregard inherited
'svn:global-ignores' properties.

Hi Daniel,
Sorry, that section is out of date, I corrected it. The --no-ignores
option still works for status, it's only for import and add that it
can't be overridden.

Perfect, thanks. I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and before
'commit').

Post by Paul Burba

Post by Daniel Shahaf
% svn status --no-ignore | xargs rm -rf
How, with a 1.8 client, would I obtain a complete list of all
unversioned files in my working copy? "Complete" means - without
excluding any files (regardless of inherited props, runtime config, etc)

M .
I merge_annotate_log_bug.py

Thanks for the detailed answer.

Cheers

Daniel

Post by Paul Burba
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

[Julian Foad]

 
--
Subversion Live 2012 - 2 Days: training, networking, demos & more! http://bit.ly/NgUaRi
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download



----- Original Message -----

Sent: Monday, 5 November 2012, 22:23
Subject: Re: disregarding svn:global-ignores

On Mon, Nov 5, 2012 at 5:41 PM, Daniel Shahaf

http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_.22Hierarchy.22

Post by Daniel Shahaf
says 'svn status --no-ignore' does not disregard inherited
'svn:global-ignores' properties.

Hi Daniel,
Sorry, that section is out of date, I corrected it.  The --no-ignores
option still works for status, it's only for import and add that it
can't be overridden.

Perfect, thanks.  I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add'
files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and before
'commit').

Am I the only one going "Eww!" on reading this?

We have three ways of specifying ignores, and we have an option that disregards them, only in one cammand it disregards all of the ways and in two other commands the option only disregards two of the ways.  And we say "sure, that sounds perfect".  It doesn't sound fine to me, it sounds horrible.

What am I missing?

- Julian

Post by Daniel Shahaf
% svn status --no-ignore | xargs rm -rf
How, with a 1.8 client, would I obtain a complete list of all
unversioned files in my working copy?  "Complete" means -

without

Post by Daniel Shahaf
excluding any files (regardless of inherited props, runtime config,

etc)

Note that the unversioned *.py files are revealed with the --no-ignore
    M      .
  I      merge_annotate_log_bug.py

Thanks for the detailed answer.
Cheers
Daniel

--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

[C. Michael Pilato]

Post by Julian Foad

Post by Daniel Shahaf

Post by Paul Burba
Sorry, that section is out of date, I corrected it. The
--no-ignores option still works for status, it's only for import and
add that it can't be overridden.

Perfect, thanks. I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and
before 'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and in
two other commands the option only disregards two of the ways. And we
say "sure, that sounds perfect". It doesn't sound fine to me, it sounds
horrible.

I would be in favor of --no-ignores working identically across all the
subcommands. I understand the arguments for "add" and "import" not allowing
the override, so I don't fault Paul for choosing the current arrangement.
But I've not been a huge fan of the idea of "server-dictated configuration"
anyway, being more in favor of "repos-default configuration" or somesuch
that doesn't pretend to be the final word on anything. With or without this
feature in place, enforcement of ignores (and auto-props, for that matter)
can only happen in the hook scripts, anyway, so I don't see the harm in
allowing a user to specify --no-ignores if his or her admin doesn't care
enough to enforce that the default configuration is honored.

[Julian Foad]

Post by C. Michael Pilato

Post by Julian Foad

Sorry, that section is out of date, I corrected it.  The
--no-ignores option still works for status, it's only for
import and add that it can't be overridden.

Perfect, thanks.  I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and
before 'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and in
two other commands the option only disregards two of the ways.  And we
say "sure, that sounds perfect".  It doesn't sound fine to me, it sounds
horrible.

I would be in favor of --no-ignores working identically across all the
subcommands.  I understand the arguments for "add" and
"import" not allowing
the override, so I don't fault Paul for choosing the current arrangement.

Oh, I don't recall such arguments.  I was particularly baffled because what was written above in this thread seemed to assume that the need for inconsistency is self-evident.

Post by C. Michael Pilato
But I've not been a huge fan of the idea of "server-dictated
configuration" anyway, being more in favor of "repos-default
configuration" or somesuch that doesn't pretend to be the
final word on anything.  With or without this feature in place,
enforcement of ignores (and auto-props, for that matter) can
only happen in the hook scripts, anyway, so I don't see the harm in
allowing a user to specify --no-ignores if his or her admin doesn't
care enough to enforce that the default configuration is honored.

Right, +1 there.

- Julian

[Paul Burba]

Post by C. Michael Pilato

Post by Julian Foad

Post by Daniel Shahaf

Post by Paul Burba
Sorry, that section is out of date, I corrected it. The
--no-ignores option still works for status, it's only for
import and add that it can't be overridden.

Perfect, thanks. I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and
before 'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and in
two other commands the option only disregards two of the ways. And we
say "sure, that sounds perfect". It doesn't sound fine to me, it sounds
horrible.

Hi Julian,

I think you are making this out to sound worse than it is. Yes there
are three ways to specify ignores. So what? How many ways are there
to add a file to a repository? Import, copy, commit, oh my, it's so
terribly confusing! (Please take this as the light hearted jest it's
meant to be ;-)

You previously proposed trying to combine svn:global-ignores with
svn:ignore in a different thread and nobody else agreed, so if that is
still a concern for you then let's move that topic to another thread.

As to the current behavior where "in one command it disregards all of
the ways and in two other commands the option only disregards two of
the ways". All I can say is that whatever we chose to do, I can't
imagine anyone arguing that the "one command" we are taking about here
('svn status') should do anything other than report *all* ignored
paths, so that's really not up for debate IMO.

So your sole objection (I think?) is to the fact that
svn:global-ignores cannot be ignored during adds or imports, right?
If so that is a totally legitimate concern. Read on for how I ended
up with that solution...

Post by C. Michael Pilato
I would be in favor of --no-ignores working identically across all the
subcommands. I understand the arguments for "add" and
"import" not allowing
the override, so I don't fault Paul for choosing the current arrangement.

Oh, I don't recall such arguments. I was particularly baffled because what was written above in this thread seemed to assume that the need for inconsistency is self-evident.

The inheritable props, svn:global-ignores, and svn:auto-props work all
came about as an alternative to the Server Dictated Configuration
effort that Mike and I had toyed around with earlier this year
(http://wiki.apache.org/subversion/ServerDictatedConfiguration). The
idea of SDC was that repository administrators could set some hard and
fast rules that could only be violated by a custom hacked client
(http://wiki.apache.org/subversion/ServerDictatedConfiguration#Behavioral_specification).
So that idea carried over to the alternative solution with inherited
properties. The assumption on my part has been that if a repos admin
sets svn:global-ignores on, say the root of their repos, then it means
they are *really* serious about keeping those files out of their
repos.

Also keep in mind that if you really want to add an ignored file you
can make the file the target of the 'svn add' command. Just like with
the runtime config global-ignores and the svn:ignore property in 1.7,
if the file in question is the explicit target of an add subcommand,
it will be added, no need for . Import works the same way.

Post by C. Michael Pilato
But I've not been a huge fan of the idea of "server-dictated
configuration" anyway, being more in favor of "repos-default
configuration" or somesuch that doesn't pretend to be the
final word on anything. With or without this feature in place,
enforcement of ignores (and auto-props, for that matter) can
only happen in the hook scripts, anyway, so I don't see the harm in
allowing a user to specify --no-ignores if his or her admin doesn't
care enough to enforce that the default configuration is honored.

Right, +1 there.

Well the beauty is that 1.8 isn't released yet! So I can change this
easily enough. If I'm the lone voice in the wilderness on this then
I'm happy to switch it so that --no-ignore works the same for
svn:global-ignores as it does for the runtime config global-ignores
and svn:ignore.

- Julian

[Julian Foad]

Post by Paul Burba

Post by Julian Foad

Post by C. Michael Pilato

Post by Julian Foad

Sorry, that section is out of date, I corrected it.  The
--no-ignores option still works for status, it's only for
import and  add that it can't be overridden.

Perfect, thanks.  I think not-overriding for add/import is fine ...

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and in
two other commands the option only disregards two of the ways.  And we
say "sure, that sounds perfect".  It doesn't sound fine to me, it sounds
horrible.

Hi Julian,
I think you are making this out to sound worse than it is.  Yes there
are three ways to specify ignores.  So what?  [...]

I didn't mean here to emphasize that there are three ways.  The same applies if there are only two.

Post by Paul Burba
You previously proposed trying to combine svn:global-ignores with
svn:ignore in a different thread and nobody else agreed, so if that is
still a concern for you then let's move that topic to another thread.

I accept the majority decision on that point -- that's no longer my concern.

Post by Paul Burba
As to the current behavior where "in one command it disregards all of
the ways and in two other commands the option only disregards two of
the ways".  All I can say is that whatever we chose to do, I can't
imagine anyone arguing that the "one command" we are taking about here
('svn status') should do anything other than report *all* ignored
paths, so that's really not up for debate IMO.

Well, on this preliminary point, 'svn status --no-ignore' should certainly report all ignored paths *if* other commands do too.  If they don't, I might well feel that consistency among commands should trump the assumption that 'svn status --no-ignore' should report all paths.  But we're not at that point yet.

Post by Paul Burba
So your sole objection (I think?) is to the fact that
svn:global-ignores cannot be ignored during adds or imports, right?
If so that is a totally legitimate concern.  Read on for how I ended
up with that solution...

Yes, that's my my main concern.

Post by Paul Burba

Post by Julian Foad

Post by C. Michael Pilato
I would be in favor of --no-ignores working identically across
all the subcommands.  I understand the arguments for "add" and
"import" not allowing the override, so I don't fault Paul for
choosing the current arrangement.

Oh, I don't recall such arguments.  I was particularly baffled
because what was written above in this thread seemed to assume
that the need for inconsistency is self-evident.

The inheritable props, svn:global-ignores, and svn:auto-props work all
came about as an alternative to the Server Dictated Configuration
effort that Mike and I had toyed around with earlier this year
(http://wiki.apache.org/subversion/ServerDictatedConfiguration).  The
idea of SDC was that repository administrators could set some hard and
fast rules that could only be violated by a custom hacked client
(http://wiki.apache.org/subversion/ServerDictatedConfiguration#Behavioral_specification).
So that idea carried over to the alternative solution with inherited
properties.  The assumption on my part has been that if a repos admin
sets svn:global-ignores on, say the root of their repos, then it means
they are *really* serious about keeping those files out of their
repos.

That original intent is just one of several use cases for inherited props.  The current design is not strongly tied to achieving that particular goal: it doesn't have any features that specifically relate to that use case, except these proposed exceptions to the --no-ignores option.

What we're ending up with is a feature that grants people an easier way to configure the very same kind of functionality that they already had (with respect to ignores).  Once this is rolled out, people will set svn:global-ignores wherever they have file patterns they don't want to be versioned in a directory tree, not just when they're "really serious".

Post by Paul Burba
Also keep in mind that if you really want to add an ignored file you
can make the file the target of the 'svn add' command.  Just like with
the runtime config global-ignores and the svn:ignore property in 1.7,
if the file in question is the explicit target of an add subcommand,
it will be added, no need for .  Import works the same way.

Well, quite!  That's consistent among all ways of specifying ignores.  Doesn't that tell us that the inherited property is not considered so special after all.  If we wanted it to be so special, we'd want to make the property override this rule as well.

Here's another perspective.  Picture a user with a fairly simple project, not much need for ignores at all to begin with.  Then they want to ignore '*.log' in their project-root directory.  Faced with the option of putting this in 'svn:ignore' or in 'svn:global-ignores', which do they choose.  Reality, they choose one or the other on a whim, unless we make it really clear that one is somehow different from the other.  And how are we going to do that?  It's not enough to describe the differences subcommand-by-subcommand; to make a clear statement we would need a system-level statement that says something like "We have a two-tier system for ignoring unwanted files; svn:ignore specifies user preferences, while svn:global-ignores specifies mandatory exclusions and of course overrides svn:ignore and is enforced by the server".  Or something.

So basically I'm saying our two sensible design options are:

  * the difference between svn:ignore and svn:global-ignores is that the latter is inherited;

or

  * there is a major distinction between svn:ignore and svn:global-ignores (which is: ... something).

No middle ground.

If we try to make it mean two things at once -- meaning "inheritable" and "specially enforced" -- then we're unnecessarily conflating two independent needs.  Instead those two meanings should be orthogonal.  If we want a "specially enforced" option, it should not be tied to "inheritable".

Post by Paul Burba

Post by Julian Foad

Post by C. Michael Pilato
But I've not been a huge fan of the idea of "server-dictated
configuration" anyway, being more in favor of "repos-default
configuration" or somesuch that doesn't pretend to be the
final word on anything.  With or without this feature in place,
enforcement of ignores (and auto-props, for that matter) can
only happen in the hook scripts, anyway, so I don't see the harm in
allowing a user to specify --no-ignores if his or her admin doesn't
care enough to enforce that the default configuration is honored.

Right, +1 there.

Well the beauty is that 1.8 isn't released yet!  So I can change this
easily enough.  If I'm the lone voice in the wilderness on this then
I'm happy to switch it so that --no-ignore works the same for
svn:global-ignores as it does for the runtime config global-ignores
and svn:ignore.

Great.  I hope my argument makes more sense to you and others now I've used a few more words (did someone say 'rant'?).

- Julian

[Daniel Shahaf]

Post by Paul Burba
Also keep in mind that if you really want to add an ignored file you
can make the file the target of the 'svn add' command. Just like with
the runtime config global-ignores and the svn:ignore property in 1.7,
if the file in question is the explicit target of an add subcommand,
it will be added, no need for . Import works the same way.

About the applicability of similar workarounds to svn:auto-props : two
options that come to mind are 'svn add foo.py && svn pd svn:eol-style
foo.py' and 'mv foo.py ___; svn add ___; svn mv ___ foo.py' (yuck). But
the back-of-the-head thought I had was, "But what if we have a process
that watches the wc, seeing changes as they happen, that sees the file
with the auto-prop in place --- or with the temporary name --- before
I had a chance to remove it?"

Making 'svn add --no-auto-props' disregard svn:auto-props is
a bulletproof solution to the above.

[Johan Corveleyn]

Post by Daniel Shahaf

Post by Paul Burba
Also keep in mind that if you really want to add an ignored file you
can make the file the target of the 'svn add' command. Just like with
the runtime config global-ignores and the svn:ignore property in 1.7,
if the file in question is the explicit target of an add subcommand,
it will be added, no need for . Import works the same way.

About the applicability of similar workarounds to svn:auto-props : two
options that come to mind are 'svn add foo.py && svn pd svn:eol-style
foo.py' and 'mv foo.py ___; svn add ___; svn mv ___ foo.py' (yuck). But
the back-of-the-head thought I had was, "But what if we have a process
that watches the wc, seeing changes as they happen, that sees the file
with the auto-prop in place --- or with the temporary name --- before
I had a chance to remove it?"
Making 'svn add --no-auto-props' disregard svn:auto-props is
a bulletproof solution to the above.

I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that? Or
does that not override the "repos-default" svn:auto-props?

Or if that doesn't work, what about 'svn add --config-option
"config:auto-props:*.py=" foo.py' ? No idea if that works ... in any
case it seems very cumbersome ...

[Stefan Sperling]

Post by Johan Corveleyn
I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that?

Nobody wants to type that! :)

And you realise the --no-auto-props option already exists in 1.7?
It's reasonable to make this existing option override the svn:auto-props
property, just like --no-ignores overrides the svn:ignore property.

[Johan Corveleyn]

Post by Stefan Sperling

Post by Johan Corveleyn
I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that?

Nobody wants to type that! :)
And you realise the --no-auto-props option already exists in 1.7?

Oops, learned something new :-). I thought Daniel was making it up.

Post by Stefan Sperling
It's reasonable to make this existing option override the svn:auto-props
property, just like --no-ignores overrides the svn:ignore property.

Indeed.

A related question then (sorry if this is in the spec or a mail-thread
-- I have read a lot of it, but haven't gone through all the details):
will a setting of enable-auto-props=no in the config file of the
user's runtime config ignore the svn:auto-props? How about when it's
set as a command line option, like my example above?

On first sight, this seems to me the best behavior:
- If enable-auto-props is not set (which is normally the case when you
have a fresh install of svn): defaults to "no" for runtime config
(miscellany), but still applies the svn:auto-props settings.
- If enable-auto-props = no -> no auto-props are applied, not even the
svn:auto-props.
- If enable-auto-props = yes -> all are applied.
- The above rules apply wherever the enable-auto-props is set (I mean:
the existing priority rules are applicable)

The first rule introduces an inconsistency between
auto-props-in-config and svn:auto-props, but for a very good reason:
it allows svn:auto-props to impact freshly installed svn clients, no
need for all end users to go fiddling in their config file to enable
the auto-props feature.

(sorry if I'm rehashing old arguments/specs/discussions ... I claim
not-able-to-follow-everything-ness :-))

[Daniel Shahaf]

Post by Johan Corveleyn

Post by Stefan Sperling

Post by Johan Corveleyn
I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that?

Nobody wants to type that! :)
And you realise the --no-auto-props option already exists in 1.7?

Oops, learned something new :-). I thought Daniel was making it up.

I wasn't making it up --- I was referring to the shiny new option that
Julian remind me existed. :)

[Paul Burba]

Post by Johan Corveleyn

Post by Stefan Sperling

Post by Johan Corveleyn
I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that?

Nobody wants to type that! :)
And you realise the --no-auto-props option already exists in 1.7?

Oops, learned something new :-). I thought Daniel was making it up.

Post by Stefan Sperling
It's reasonable to make this existing option override the svn:auto-props
property, just like --no-ignores overrides the svn:ignore property.

Indeed.
A related question then (sorry if this is in the spec or a mail-thread
will a setting of enable-auto-props=no in the config file of the
user's runtime config ignore the svn:auto-props?

No it won't.

Post by Johan Corveleyn
How about when it's
set as a command line option, like my example above?

No again.

Post by Johan Corveleyn
- If enable-auto-props is not set (which is normally the case when you
have a fresh install of svn): defaults to "no" for runtime config
(miscellany), but still applies the svn:auto-props settings.
- If enable-auto-props = no -> no auto-props are applied, not even the
svn:auto-props.
- If enable-auto-props = yes -> all are applied.
the existing priority rules are applicable)

As best I can tell we all agree now that a user should be able to
disregard the svn:auto-props with --no-auto-props option. Having
digested everyone's arguments on that topic I'm fine with that now.

However I strongly believe that the default behavior of svn:auto-props
should not be tied the config:miscellany:enable-auto-props runtime
setting. Doing so makes it too easy for users to permanently (and
perhaps accidentally) disregard svn:auto-props. We want to give users
to opportunity to override the repository recommended auto-props (as
manifested in the svn:auto-props property) on an exception basis, but
do we want to make it easy for users to simply "turn off" the repos
recommended auto-props? Personally I think not. I assume a
repository administrator who sets an svn:auto-props property on the
root of their repos considers these autoprops the recommended default,
only to be overridden in special circumstances, not something that can
simply be switched off permanently by disinterested users.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

Post by Johan Corveleyn
The first rule introduces an inconsistency between
it allows svn:auto-props to impact freshly installed svn clients, no
need for all end users to go fiddling in their config file to enable
the auto-props feature.
(sorry if I'm rehashing old arguments/specs/discussions ... I claim
not-able-to-follow-everything-ness :-))
--
Johan

[Julian Foad]

Post by Paul Burba
As best I can tell we all agree now that a user should be able to
disregard the svn:auto-props with --no-auto-props option.  Having
digested everyone's arguments on that topic I'm fine with that now.
However I strongly believe that the default behavior of svn:auto-props
should not be tied the config:miscellany:enable-auto-props runtime
setting.

+1, but for this reason alone:  We don't want new users to have to tweak their config before these auto-props will take effect.  (The setting defaults to off, which was fine for its original purpose because you had to edit the config anyway to use auto-props so having to change this setting at the same time was no big deal.)

I think your argument here ...

Post by Paul Burba
  Doing so makes it too easy for users to permanently (and
perhaps accidentally) disregard svn:auto-props.  We want to give users
to opportunity to override the repository recommended auto-props (as
manifested in the svn:auto-props property) on an exception basis, but
do we want to make it easy for users to simply "turn off" the repos
recommended auto-props?  Personally I think not.  I assume a
repository administrator who sets an svn:auto-props property on the
root of their repos considers these autoprops the recommended default,
only to be overridden in special circumstances, not something that can
simply be switched off permanently by disinterested users.

... is too hung up on the notion that this is a repos-dictated config.  It's not.  The feature you have created is a per-subtree, user-controlled config.  I bet the only auto-props that get set in our repo[1] will not be at the
root but at the "^/subversion/" level or deeper, and I bet they will
only be done by us for our own convenience, not demanded by any repository administrator.

I'm not saying users need an on/off switch for in-tree auto-props, but the idea of giving them one is not conceptually different from giving them the existing switch for config-file auto-props.  If the project rules require certain props to be set, then the project members have until now been socially required to ensure that either their auto-props are enabled or they remember to set the required props in some other way.  That same obligation will exist with the in-tree auto-props.  If a user -- or a build-slave machine -- wants to globally turn off auto-props, let him/her/it do so.

So we do not need to be afraid of letting the user have such a switch, if someone were to come to us with a good reason for adding one.  The important thing, rather, is to make it easy to do the common things -- comply with in-tree auto-props -- and that is why I agree the existing switch (because it defaults to off for new users) should not control it.

- Julian


[1] Not that
everybody's situations are like ours, of course, but many are.

[Daniel Shahaf]

Post by Paul Burba
However I strongly believe that the default behavior of svn:auto-props
should not be tied the config:miscellany:enable-auto-props runtime
setting. Doing so makes it too easy for users to permanently (and
perhaps accidentally) disregard svn:auto-props. We want to give users
to opportunity to override the repository recommended auto-props (as
manifested in the svn:auto-props property) on an exception basis, but
do we want to make it easy for users to simply "turn off" the repos
recommended auto-props? Personally I think not.

Maybe your conclusion is correct, but the argument you give for it ---
the one below, "repos admin convenience" --- is not sufficient: it would
also justify letting repository administrators dictate the contents of
client-side hooks (if we ever grow that feature), which is not something
we would find acceptable.

Post by Paul Burba
I assume a
repository administrator who sets an svn:auto-props property on the
root of their repos considers these autoprops the recommended default,
only to be overridden in special circumstances, not something that can
simply be switched off permanently by disinterested users.

[Daniel Shahaf]

Post by Stefan Sperling

Post by Johan Corveleyn
I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that?

Nobody wants to type that! :)
And you realise the --no-auto-props option already exists in 1.7?

Is it equivalent, though? --config-option would change the svn_config_t
in the client ctx, but for all I know --no-auto-props might map to an
svn_boolean_t argument to some client API.

i.e., maybe --no-auto-props would work and --config-option wouldn't...

Post by Stefan Sperling
It's reasonable to make this existing option override the svn:auto-props
property, just like --no-ignores overrides the svn:ignore property.

[Paul Burba]

Post by Johan Corveleyn

Post by Daniel Shahaf

Post by Paul Burba
Also keep in mind that if you really want to add an ignored file you
can make the file the target of the 'svn add' command. Just like with
the runtime config global-ignores and the svn:ignore property in 1.7,
if the file in question is the explicit target of an add subcommand,
it will be added, no need for . Import works the same way.

About the applicability of similar workarounds to svn:auto-props : two
options that come to mind are 'svn add foo.py && svn pd svn:eol-style
foo.py' and 'mv foo.py ___; svn add ___; svn mv ___ foo.py' (yuck). But
the back-of-the-head thought I had was, "But what if we have a process
that watches the wc, seeing changes as they happen, that sees the file
with the auto-prop in place --- or with the temporary name --- before
I had a chance to remove it?"
Making 'svn add --no-auto-props' disregard svn:auto-props is
a bulletproof solution to the above.

I haven't tested, but wouldn't something like 'svn add --config-option
config:miscellany:enable-auto-props=no' do something like that? Or
does that not override the "repos-default" svn:auto-props?

Hi Johan,

It doesn't. Runtime config options, including those specified via
--config-dir or --config-option, have no effect on how the new
svn:auto-props property is used.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

Post by Johan Corveleyn
Or if that doesn't work, what about 'svn add --config-option
"config:auto-props:*.py=" foo.py' ? No idea if that works ... in any
case it seems very cumbersome ...
--
Johan

[Markus Schaber]

Hi,

-----Ursprüngliche Nachricht-----

Post by Julian Foad

Post by C. Michael Pilato

Post by Julian Foad
We have three ways of specifying ignores, and we have an option
that disregards them, only in one cammand it disregards all of the
ways and in two other commands the option only disregards two of
the ways. And we say "sure, that sounds perfect". It doesn't
sound fine to me, it sounds horrible.

[ ...]
The assumption on my part has been that if a repos admin sets
svn:global-ignores on, say the root of their repos, then it means they are
*really* serious about keeping those files out of their repos.

When an admin really is "really serious" about keeping files out of the
repository, then (s)he should use a pre-commit hook to prevent commit of
those files on the server side.

Client-Side ignore properties are never 100% safe:
- Commit in an updated subdirectory, where the parent directory has the
property set, but the parent dir in the working copy still has an old
revision without the property set.
- old client versions.
- autoversioning.
- svnkit.
- "hacked" / source-level customized clients.
- maybe svnmucc & co if they are not updated to honor those rules.

In my eyes, "ignored" != "forbidden".

The foolproof way would be to add a svn:global-forbidden property which is
checked on the server side, and aborts the commit. (Clients could use
that property as a fast-path check, additionally). AFAICS, such a beast
could be implemented as a hook script, but I could also imagine it in core
svn.

Post by Julian Foad

Post by C. Michael Pilato
But I've not been a huge fan of the idea of "server-dictated
configuration" anyway, being more in favor of "repos-default
configuration" or somesuch that doesn't pretend to be the final word
on anything. With or without this feature in place, enforcement of
ignores (and auto-props, for that matter) can only happen in the hook
scripts, anyway, so I don't see the harm in allowing a user to
specify --no-ignores if his or her admin doesn't care enough to
enforce that the default configuration is honored.

Right, +1 there.

Well the beauty is that 1.8 isn't released yet! So I can change this
easily enough. If I'm the lone voice in the wilderness on this then I'm
happy to switch it so that --no-ignore works the same for svn:global-
ignores as it does for the runtime config global-ignores and svn:ignore.

I'm neither a core developer, nor a sysadmin, but I tend to prefer
--no-ignore behaving the same for all 3 types of ignores, and using hooks
for "waterproof" blocking of files.


Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. [phone] | Fax [phone]

E-Mail: ***@codesys.com | Web: http://www.codesys.com
CODESYS internet forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Ta

[Branko Čibej]

Post by Markus Schaber
In my eyes, "ignored" != "forbidden".

Precisely. "ignored" has /never/ meant that you couldn't "svn add" a
file that matches the ignore pattern. Therefore, --no-ignores should
always ignore all ignores.

-- Brane

[Peter Samuelson]

[Branko Čibej]

"ignored" has /never/ meant that you couldn't "svn add" a file that
matches the ignore pattern. Therefore, --no-ignores should always
ignore all ignores.

And for people who want the other behavior, maybe we could add a
--no-ignores-well-ok-fine-maybe-some-ignores-but-not-all-ignores.

Peter

[Daniel Shahaf]

Post by Julian Foad
----- Original Message -----

Sent: Monday, 5 November 2012, 22:23
Subject: Re: disregarding svn:global-ignores

On Mon, Nov 5, 2012 at 5:41 PM, Daniel Shahaf

http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_.22Hierarchy.22

Post by Daniel Shahaf
says 'svn status --no-ignore' does not disregard inherited
'svn:global-ignores' properties.

Hi Daniel,
Sorry, that section is out of date, I corrected it.  The --no-ignores
option still works for status, it's only for import and add that it
can't be overridden.

Perfect, thanks.  I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and before
'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that disregards them, only in one cammand it disregards all of the ways and in two other commands the option only disregards two of the ways.  And we say "sure, that sounds perfect".  It doesn't sound fine to me, it sounds horrible.
What am I missing?

Do 'add' and 'import' already take the '--no-ignore' flag? My answer
was assuming they didn't.

Also Julian you might want to review the semantics of svn:auto-props?
According to the wiki page there is no way to override or ignore those
upon add/import, either - I'm not completely happy with that.

Post by Julian Foad
- Julian

Post by Daniel Shahaf
% svn status --no-ignore | xargs rm -rf
How, with a 1.8 client, would I obtain a complete list of all
unversioned files in my working copy?  "Complete" means -

without

Post by Daniel Shahaf
excluding any files (regardless of inherited props, runtime config,

etc)

Note that the unversioned *.py files are revealed with the --no-ignore
    M      .
  I      merge_annotate_log_bug.py

Thanks for the detailed answer.
Cheers
Daniel

--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

[Julian Foad]

Post by Julian Foad

Perfect, thanks.  I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and
before 'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and
in two other commands the option only disregards two of the ways.  And
we say "sure, that sounds perfect".  It doesn't sound fine to me, it
sounds horrible.
What am I missing?

Do 'add' and 'import' already take the '--no-ignore' flag?  My answer
was assuming they didn't.

They do.

Also Julian you might want to review the semantics of svn:auto-props?
According to the wiki page there is no way to override or ignore those
upon add/import, either - I'm not completely happy with that.

Thanks, I'll try to review that too.

- Julian

[Paul Burba]

Post by Julian Foad

Post by Daniel Shahaf

Post by Julian Foad

Post by Daniel Shahaf
Perfect, thanks. I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and
before 'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and
in two other commands the option only disregards two of the ways. And
we say "sure, that sounds perfect". It doesn't sound fine to me, it
sounds horrible.
What am I missing?

Do 'add' and 'import' already take the '--no-ignore' flag? My answer
was assuming they didn't.

They do.

Post by Daniel Shahaf
Also Julian you might want to review the semantics of svn:auto-props?
According to the wiki page there is no way to override or ignore those
upon add/import, either - I'm not completely happy with that.

Thanks, I'll try to review that too.

If we ultimately decide[1] to allow svn:global-ignores to be
disregarded with the --no-ignore option, then I suggest it makes sense
for 'svn add' and 'svn import' to disregard the svn:auto-props
property when the --no-auto-props option is used. Anyone disagree?

[1] And it certainly looks as if we are going in that direction. I'll
give this thread a day before making any changes, so all interested
parties have a chance to weigh in.

[Ivan Zhakov]

Post by Paul Burba

Post by Julian Foad

Post by Daniel Shahaf

Post by Julian Foad

Post by Daniel Shahaf
Perfect, thanks. I think not-overriding for add/import is fine: for
'import' only the repository files are affected, and for 'add' files
matching the pattern can be specified explicitly in the argv targets
(and auto-props added can be modified or stripped after 'add' and
before 'commit').

Am I the only one going "Eww!" on reading this?
We have three ways of specifying ignores, and we have an option that
disregards them, only in one cammand it disregards all of the ways and
in two other commands the option only disregards two of the ways. And
we say "sure, that sounds perfect". It doesn't sound fine to me, it
sounds horrible.
What am I missing?

Do 'add' and 'import' already take the '--no-ignore' flag? My answer
was assuming they didn't.

They do.

Post by Daniel Shahaf
Also Julian you might want to review the semantics of svn:auto-props?
According to the wiki page there is no way to override or ignore those
upon add/import, either - I'm not completely happy with that.

Thanks, I'll try to review that too.

If we ultimately decide[1] to allow svn:global-ignores to be
disregarded with the --no-ignore option, then I suggest it makes sense
for 'svn add' and 'svn import' to disregard the svn:auto-props
property when the --no-auto-props option is used. Anyone disagree?
[1] And it certainly looks as if we are going in that direction. I'll
give this thread a day before making any changes, so all interested
parties have a chance to weigh in.

I think that svn:global-ignores should work the same as svn:ignore. So
if --no-ignore option disregard svn:ignore then it should disregard
svn:global-ignores.

This is also true for svn:auto-props.

/bike-shed note: why property named "svn:global-ignores", not
"svn:global-ignore"? It will be looking more consistent with
"svn:ignore".

[Stefan Sperling]

Post by Ivan Zhakov
/bike-shed note: why property named "svn:global-ignores", not
"svn:global-ignore"? It will be looking more consistent with
"svn:ignore".

The name mirrors the "global-ignores" option in the configuration file.
That's not a very strong argument, of course.
A more convincing argument against changing it is that changing it
involves changing lots of lines of code, see r1405834 :)

[Johan Corveleyn]

Post by Stefan Sperling

Post by Ivan Zhakov
/bike-shed note: why property named "svn:global-ignores", not
"svn:global-ignore"? It will be looking more consistent with
"svn:ignore".

The name mirrors the "global-ignores" option in the configuration file.
That's not a very strong argument, of course.
A more convincing argument against changing it is that changing it
involves changing lots of lines of code, see r1405834 :)

At the risk of getting something thrown at me: after reading Julian's
arguments, I was thinking "svn:recursive-ignore" might be a better
name. It doesn't sound as global, and it does adequately describe what
it does as opposed to svn:ignore. (except if it doesn't ... not
entirely sure if "recursive" is accurate for the current behavior).

</whisper-voice>

--
Johan

[Paul Burba]

Post by Johan Corveleyn

Post by Stefan Sperling

Post by Ivan Zhakov
/bike-shed note: why property named "svn:global-ignores", not
"svn:global-ignore"? It will be looking more consistent with
"svn:ignore".

The name mirrors the "global-ignores" option in the configuration file.
That's not a very strong argument, of course.
A more convincing argument against changing it is that changing it
involves changing lots of lines of code, see r1405834 :)

At the risk of getting something thrown at me: after reading Julian's
arguments, I was thinking "svn:recursive-ignore" might be a better
name. It doesn't sound as global, and it does adequately describe what
it does as opposed to svn:ignore. (except if it doesn't ... not
entirely sure if "recursive" is accurate for the current behavior).

Hi Johan,

I suspect that "svn:recursive-ignore" will find disfavor for the same
reason my original "svn:inheritable-ignores" did: Nobody embraced the
idea of explicitly declaring the property as inheritable (or
recursive) as part of its name. Just replace "inheritable" with
"recursive" in this thread and you'll see what I mean:
http://svn.haxx.se/dev/archive-2012-11/0005.shtml

[Johan Corveleyn]

Post by Paul Burba

Post by Johan Corveleyn

Post by Stefan Sperling

Post by Ivan Zhakov
/bike-shed note: why property named "svn:global-ignores", not
"svn:global-ignore"? It will be looking more consistent with
"svn:ignore".

The name mirrors the "global-ignores" option in the configuration file.
That's not a very strong argument, of course.
A more convincing argument against changing it is that changing it
involves changing lots of lines of code, see r1405834 :)

At the risk of getting something thrown at me: after reading Julian's
arguments, I was thinking "svn:recursive-ignore" might be a better
name. It doesn't sound as global, and it does adequately describe what
it does as opposed to svn:ignore. (except if it doesn't ... not
entirely sure if "recursive" is accurate for the current behavior).

Hi Johan,
I suspect that "svn:recursive-ignore" will find disfavor for the same
reason my original "svn:inheritable-ignores" did: Nobody embraced the
idea of explicitly declaring the property as inheritable (or
recursive) as part of its name. Just replace "inheritable" with
http://svn.haxx.se/dev/archive-2012-11/0005.shtml

Yeah, sorry I didn't participate in that thread. But I don't actually
agree that it's the same (though you could be right about the similar
dislike by others ... don't know). The term "recursive" sounds to me
more like it describes the behavior of the ignore pattern (like
'**/*.py' would to me also indicate a recursive pattern). While
"inheritable" is more an implementation detail of the props mechanism
that we use for that.

So to me, "recursive" sounds a lot like "global" (unlike
"inheritable"), except that it's not global but only effective in that
subtree.

But I'm not a native English speaker, so I could be wrong in the
"sounds a lot like" area ... and I'm late in the bikeshedding game
anyway ... so not pushing for anything :-) ...

--
Johan

[Julian Foad]

Post by Johan Corveleyn

Post by Paul Burba

Post by Johan Corveleyn
At the risk of getting something thrown at me: after reading
Julian's arguments, I was thinking "svn:recursive-ignore" might
be a better name. It doesn't sound as global, and it does
adequately describe what it does as opposed to svn:ignore.
(except if it doesn't ... not entirely sure if "recursive" is
accurate for the current behavior).

I suspect that "svn:recursive-ignore" will find disfavor for the
same reason my original "svn:inheritable-ignores" did: Nobody
embraced the
idea of explicitly declaring the property as inheritable (or
recursive) as part of its name.  Just replace "inheritable" with
http://svn.haxx.se/dev/archive-2012-11/0005.shtml

The argument about not calling it 'recursive-foo' works well for the 'svn:auto-props' case: the point is that the name describes the main function and the fact that it's recursive is a minor detail.  But that argument doesn't work at all when we have two versions of a property
and the distinction between them is precisely that one is
non-inheritable and the other is inheritable.  Then indicating that distinction in the name is entirely appropriate.

Post by Johan Corveleyn
Yeah, sorry I didn't participate in that thread. But I don't actually
agree that it's the same (though you could be right about the similar
dislike by others ... don't know). The term "recursive" sounds to
me more like it describes the behavior of the ignore pattern (like
'**/*.py' would to me also indicate a recursive pattern). While
"inheritable" is more an implementation detail of the props mechanism
that we use for that.
So to me, "recursive" sounds a lot like "global" (unlike
"inheritable"), except that it's not global but only effective in
that subtree.
But I'm not a native English speaker, so I could be wrong in the
"sounds a lot like" area ... and I'm late in the bikeshedding game
anyway ... so not pushing for anything :-) ...

I agree with Johan that 'recursive' sounds more intuitive than 'inheritable' (largely because we already use 'recursive' in the UI and docs), and also more appropriate than 'global'.  On the other hand, 'global' is shorter and is the name used in the config file, which would help people to recognize it even though it's not quite the same scope.  Overall I'd call it a draw.  The world could just as easily get used to either name.

- Julian

[Paul Burba]

Post by Paul Burba
If we ultimately decide[1] to allow svn:global-ignores to be
disregarded with the --no-ignore option, then I suggest it makes sense
for 'svn add' and 'svn import' to disregard the svn:auto-props
property when the --no-auto-props option is used. Anyone disagree?
[1] And it certainly looks as if we are going in that direction. I'll
give this thread a day before making any changes, so all interested
parties have a chance to weigh in.
I'm neither a core developer, nor a sysadmin, but I tend to prefer
--no-ignore behaving the same for all 3 types of ignores, and using hooks
for "waterproof" blocking of files.
Making 'svn add --no-auto-props' disregard svn:auto-props is
a bulletproof solution to the above.
Precisely. "ignored" has /never/ meant that you couldn't "svn add" a
file that matches the ignore pattern. Therefore, --no-ignores should
always ignore all ignores.

I believe we have consensus at this point. So I'm going to make the
requisite changes so that svn:global-ignores are disregarded with the
--no-ignore option and svn:auto-props are disregarded when the
--no-auto-props option is used.