You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2012/11/05 23:41:41 UTC
disregarding svn:global-ignores
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)
Re: disregarding svn:global-ignores
Posted by Julian Foad <ju...@btopenworld.com>.
Johan Corveleyn wrote:
> On Tue, Nov 6, 2012 at 8:55 PM, Paul Burba wrote:
>> On Tue, Nov 6, 2012 at 2:33 PM, Johan Corveleyn wrote:
>>> 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
>> "recursive" in this thread and you'll see what I mean:
>> 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.
> 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
Re: disregarding svn:global-ignores
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Nov 6, 2012 at 8:55 PM, Paul Burba <pt...@gmail.com> wrote:
> On Tue, Nov 6, 2012 at 2:33 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Tue, Nov 6, 2012 at 8:22 PM, Stefan Sperling <st...@elego.de> wrote:
>>>
>>> On Tue, Nov 06, 2012 at 11:06:51PM +0400, Ivan Zhakov wrote:
>>> > /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
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
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Nov 6, 2012 at 2:33 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Nov 6, 2012 at 8:22 PM, Stefan Sperling <st...@elego.de> wrote:
>>
>> On Tue, Nov 06, 2012 at 11:06:51PM +0400, Ivan Zhakov wrote:
>> > /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
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
> </whisper-voice>
>
> --
> Johan
Re: disregarding svn:global-ignores
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Nov 6, 2012 at 8:22 PM, Stefan Sperling <st...@elego.de> wrote:
>
> On Tue, Nov 06, 2012 at 11:06:51PM +0400, Ivan Zhakov wrote:
> > /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
Re: disregarding svn:global-ignores
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Nov 06, 2012 at 11:06:51PM +0400, Ivan Zhakov wrote:
> /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 :)
Re: disregarding svn:global-ignores
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, Nov 6, 2012 at 10:49 PM, Paul Burba <pt...@gmail.com> wrote:
> On Tue, Nov 6, 2012 at 1:31 PM, Julian Foad <ju...@btopenworld.com> wrote:
>> Daniel Shahaf wrote:
>>
>>> Julian Foad wrote:
>>>> Daniel Shahaf wrote:
>>>> > 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.
>
> 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".
--
Ivan Zhakov
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Nov 6, 2012 at 1:49 PM, Paul Burba <pt...@gmail.com> wrote:
> 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.
On Wed, Nov 7, 2012 at 2:40 AM, Markus Schaber <m....@codesys.com> wrote:
> 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.
On Wed, Nov 7, 2012 at 2:52 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Making 'svn add --no-auto-props' disregard svn:auto-props is
> a bulletproof solution to the above.
On Wed, Nov 7, 2012 at 4:39 AM, Branko Cibej <br...@wandisco.com> wrote:
> 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.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Nov 6, 2012 at 1:31 PM, Julian Foad <ju...@btopenworld.com> wrote:
> Daniel Shahaf wrote:
>
>> Julian Foad wrote:
>>> Daniel Shahaf wrote:
>>> > 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.
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.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: disregarding svn:global-ignores
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> Julian Foad wrote:
>> Daniel Shahaf wrote:
>> > 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
Re: disregarding svn:global-ignores
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Tue, Nov 06, 2012 at 15:29:33 +0000:
> ----- Original Message -----
> > From: Daniel Shahaf <d....@daniel.shahaf.name>
> > To: Paul Burba <pt...@gmail.com>
> > Cc: dev@subversion.apache.org
> > Sent: Monday, 5 November 2012, 22:23
> > Subject: Re: disregarding svn:global-ignores
> >
> > Paul Burba wrote on Mon, Nov 05, 2012 at 21:45:23 -0500:
> >> On Mon, Nov 5, 2012 at 5:41 PM, Daniel Shahaf
> > <d....@daniel.shahaf.name> wrote:
> >> >
> > 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').
>
> 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.
> - Julian
>
>
> >
> >> > 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)
> >>
> >> Here's my trunk WC (with no global-ignores set in my config):
> >>
> >> Note that the unversioned *.py files are revealed with the --no-ignore
> > option:
> >>
> >> trunk@1406029>svn st --depth immediates --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
> >
Re: disregarding svn:global-ignores
Posted by Peter Samuelson <pe...@p12n.org>.
[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
Re: AW: disregarding svn:global-ignores
Posted by Branko Čibej <br...@wandisco.com>.
On 07.11.2012 08:40, Markus Schaber wrote:
> 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
AW: disregarding svn:global-ignores
Posted by Markus Schaber <m....@codesys.com>.
Hi,
-----Ursprüngliche Nachricht-----
> Von: Paul Burba [mailto:ptburba@gmail.com]
> >> On 11/06/2012 10:29 AM, Julian Foad wrote:
> >>> 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.
> >> 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. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@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 | Tax ID No.: DE 167014915>
Re: disregarding svn:global-ignores
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> On Tue, Nov 6, 2012 at 11:20 AM, Julian Foad wrote:
>> C. Michael Pilato wrote:
>>> On 11/06/2012 10:29 AM, Julian Foad wrote:
>>>>>> 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.
> 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.
> 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.
> 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.
>>> 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".
> 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".
>>> 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
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Nov 7, 2012 at 3:40 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Nov 7, 2012 at 8:52 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Paul Burba wrote on Tue, Nov 06, 2012 at 12:01:54 -0500:
>>> 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
> 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
Re: disregarding svn:global-ignores
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Wed, Nov 07, 2012 at 11:48:59 +0100:
> On Wed, Nov 07, 2012 at 09:40:48AM +0100, Johan Corveleyn wrote:
> > 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...
> It's reasonable to make this existing option override the svn:auto-props
> property, just like --no-ignores overrides the svn:ignore property.
Re: disregarding svn:global-ignores
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Paul Burba wrote on Wed, Nov 07, 2012 at 16:10:00 -0500:
> 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.
> 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.
Inheritable svn:auto-props and the enable-auto-props config [was: disregarding svn:global-ignores]
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> 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 ...
> 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.
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Nov 7, 2012 at 6:06 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Nov 7, 2012 at 11:48 AM, Stefan Sperling <st...@elego.de> wrote:
>> On Wed, Nov 07, 2012 at 09:40:48AM +0100, Johan Corveleyn wrote:
>>> 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.
>
>> 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?
No it won't.
> How about when it's
> set as a command line option, like my example above?
No again.
> 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)
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
> 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 :-))
>
> --
> Johan
Re: disregarding svn:global-ignores
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Wed, Nov 07, 2012 at 12:06:22 +0100:
> On Wed, Nov 7, 2012 at 11:48 AM, Stefan Sperling <st...@elego.de> wrote:
> > On Wed, Nov 07, 2012 at 09:40:48AM +0100, Johan Corveleyn wrote:
> >> 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. :)
Re: disregarding svn:global-ignores
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Nov 7, 2012 at 11:48 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Nov 07, 2012 at 09:40:48AM +0100, Johan Corveleyn wrote:
>> 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.
> 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 :-))
--
Johan
Re: disregarding svn:global-ignores
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Nov 07, 2012 at 09:40:48AM +0100, Johan Corveleyn wrote:
> 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.
Re: disregarding svn:global-ignores
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Nov 7, 2012 at 8:52 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Paul Burba wrote on Tue, Nov 06, 2012 at 12:01:54 -0500:
>> 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 ...
--
Johan
Re: disregarding svn:global-ignores
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Paul Burba wrote on Tue, Nov 06, 2012 at 12:01:54 -0500:
> 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.
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Nov 6, 2012 at 11:20 AM, Julian Foad <ju...@btopenworld.com> wrote:
> C. Michael Pilato wrote:
>
>> On 11/06/2012 10:29 AM, Julian Foad wrote:
>>>>> 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...
>> 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.
>> 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
Re: disregarding svn:global-ignores
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> On 11/06/2012 10:29 AM, Julian Foad wrote:
>>>> 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.
> 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
Re: disregarding svn:global-ignores
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/06/2012 10:29 AM, Julian Foad wrote:
>>> 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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: disregarding svn:global-ignores
Posted by Julian Foad <ju...@btopenworld.com>.
--
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 -----
> From: Daniel Shahaf <d....@daniel.shahaf.name>
> To: Paul Burba <pt...@gmail.com>
> Cc: dev@subversion.apache.org
> Sent: Monday, 5 November 2012, 22:23
> Subject: Re: disregarding svn:global-ignores
>
> Paul Burba wrote on Mon, Nov 05, 2012 at 21:45:23 -0500:
>> On Mon, Nov 5, 2012 at 5:41 PM, Daniel Shahaf
> <d....@daniel.shahaf.name> wrote:
>> >
> 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').
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
>
>> > 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)
>>
>> Here's my trunk WC (with no global-ignores set in my config):
>>
>> Note that the unversioned *.py files are revealed with the --no-ignore
> option:
>>
>> trunk@1406029>svn st --depth immediates --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
>
Re: disregarding svn:global-ignores
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Paul Burba wrote on Mon, Nov 05, 2012 at 21:45:23 -0500:
> On Mon, Nov 5, 2012 at 5:41 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > 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').
> > 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)
>
> Here's my trunk WC (with no global-ignores set in my config):
>
> Note that the unversioned *.py files are revealed with the --no-ignore option:
>
> trunk@1406029>svn st --depth immediates --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
Re: disregarding svn:global-ignores
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Nov 5, 2012 at 5:41 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> 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.
> 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)
Here's my trunk WC (with no global-ignores set in my config):
trunk@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:
trunk@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:
trunk@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
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba