You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by James French <Ja...@naturalmotion.com> on 2012/04/17 17:18:39 UTC
default ignores
Hi group,
Just wanted to have a bit of rant about the default ignores that subversion clients have since its cost us so much time and hassle. I would like to argue that there should be no default ignores - let the client (customer) deal with it.
The '.a' ignore has particularly hurt us. I've lost count of the times that developers have checked in third party SDKs into a 'buildtools' type repository only to later find out that a load of .a files were missing. I just think its a terrible default.
The latest thing to hit us was in our build scripts that do drops from a perforce repo and create vendor branches etc, which has messed up the vendor branches because a script somewhere was not correctly countermanding the default ignores.
This has happened so many times to so many developers over the years that I felt I should say something.
Anyone else agree?
It would be lovely to be able to set up ignores centrally too without relying on individual devs to get it right.
Cheers,
James
RE: default ignores
Posted by James French <Ja...@naturalmotion.com>.
Sorry for late reply - thanks for that information Johan. Glad that there's work going on in this area :)
-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com]
Sent: 18 April 2012 16:32
To: James French
Cc: Les Mikesell; Subversion Users
Subject: Re: default ignores
On Wed, Apr 18, 2012 at 10:00 AM, James French <Ja...@naturalmotion.com> wrote:
>
> ________________________________________
> From: Les Mikesell [lesmikesell@gmail.com]
> Sent: 17 April 2012 19:34
> To: James French
> Cc: Subversion Users
> Subject: Re: default ignores
>
> On Tue, Apr 17, 2012 at 1:08 PM, James French
> <Ja...@naturalmotion.com> wrote:
>>
>> I would say that it is up to the user to check their commit and if it contains unwanted files then that fact should be visible to them and they can un-add them and set up an ignore if appropriate.
>
> Sorry, but no. A user can't ever un-add something he has committed to
> a repository. And it is an unreasonable amount of admin time/work for
> the administrator to do it with an svnadmin dump/filter/load cycle.
>
>> Silently failing to add important files I think is worse because you simply don't know that its happened until something goes wrong later.
>
> But you just said the user was supposed to check... It is easy to add
> the missed files, but you can't un-add.
>
>> I still believe that svn is a source control system that each user must take responsibility for and configure how they want.
>
> Of course, but defaults should be there for the common case.
>
>> I don't think that config decisions should be taken by the core product. What if a '.a' file means something else on a different platform? Its the arbitrary nature of the excludes I don't like either (ie primarily supports the svn dev's main platform).
>
> That's why it is in a config file, not hardcoded. Make it do whatever
> you want. Perhaps the clients should make it easier to see the config
> and change it instead of just dropping a normally hidden file
> somewhere, but that doesn't make having defaults wrong or less useful.
>
>> One could organise it so the build trees are separate to source trees which completely gets round the problem of accidentally checking in object files... This is what I've got but I'm being penalised because other people mix their build output files in with their source.
>
> There is a worse problem of committing binaries in the mix, especially
> if you combine a lot of projects in one repository. How big can the
> repository potentially grow and how long do you want to be down when
> the time comes to rearrange or clean it up with some dump/load passes?
> Or can we just expect hardware speed and capacity to stay ahead of
> this problem forever?
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> Fair points. In my first point I did mean pre-commit though. I certainly take your point about irreversible repository bloat though. I think we both agree that a *per-repository* central config system would be great. Then I could have all the lovely ignores on the repositories that contain source code and no ignores on the repositorys that contain SDKs, 3rd party distros, artwork, animation resources etc etc (where it can really hurt when you've got twenty artists plowing stuff in that don't know much about subversion). That's what I really need. Unless its per-repository the problem always remains.
>
You may be interested to know that work is being done currently on "inheritable properties", with amongst others the goal of enabling "repository dictated configuration" (with svn:ignore or global-ignores definitely on the radar as a concrete use case). It's too early to tell how it will turn out concretely, and when it will be finished.
But I'd just thought of letting you know that there may be some improvement on the horizon.
See this design doc on the wiki:
http://wiki.apache.org/subversion/InheritedProperties
And a dev-thread with lots of discussion (note: it's a long thread, but contains some interesting discussions and ideas, amongst others about the ignore property):
http://svn.haxx.se/dev/archive-2012-01/0032.shtml
Paul Burba is currently working on a feature branch to see how the current design (see wiki) turns out in practice:
http://svn.apache.org/viewvc/subversion/branches/inheritable-props/
--
Johan
Re: default ignores
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 18, 2012 at 10:00 AM, James French
<Ja...@naturalmotion.com> wrote:
>
> ________________________________________
> From: Les Mikesell [lesmikesell@gmail.com]
> Sent: 17 April 2012 19:34
> To: James French
> Cc: Subversion Users
> Subject: Re: default ignores
>
> On Tue, Apr 17, 2012 at 1:08 PM, James French
> <Ja...@naturalmotion.com> wrote:
>>
>> I would say that it is up to the user to check their commit and if it contains unwanted files then that fact should be visible to them and they can un-add them and set up an ignore if appropriate.
>
> Sorry, but no. A user can't ever un-add something he has committed to
> a repository. And it is an unreasonable amount of admin time/work for
> the administrator to do it with an svnadmin dump/filter/load cycle.
>
>> Silently failing to add important files I think is worse because you simply don't know that its happened until something goes wrong later.
>
> But you just said the user was supposed to check... It is easy to add
> the missed files, but you can't un-add.
>
>> I still believe that svn is a source control system that each user must take responsibility for and configure how they want.
>
> Of course, but defaults should be there for the common case.
>
>> I don't think that config decisions should be taken by the core product. What if a '.a' file means something else on a different platform? Its the arbitrary nature of the excludes I don't like either (ie primarily supports the svn dev's main platform).
>
> That's why it is in a config file, not hardcoded. Make it do whatever
> you want. Perhaps the clients should make it easier to see the config
> and change it instead of just dropping a normally hidden file
> somewhere, but that doesn't make having defaults wrong or less useful.
>
>> One could organise it so the build trees are separate to source trees which completely gets round the problem of accidentally checking in object files... This is what I've got but I'm being penalised because other people mix their build output files in with their source.
>
> There is a worse problem of committing binaries in the mix, especially
> if you combine a lot of projects in one repository. How big can the
> repository potentially grow and how long do you want to be down when
> the time comes to rearrange or clean it up with some dump/load passes?
> Or can we just expect hardware speed and capacity to stay ahead of
> this problem forever?
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> Fair points. In my first point I did mean pre-commit though. I certainly take your point about irreversible repository bloat though. I think we both agree that a *per-repository* central config system would be great. Then I could have all the lovely ignores on the repositories that contain source code and no ignores on the repositorys that contain SDKs, 3rd party distros, artwork, animation resources etc etc (where it can really hurt when you've got twenty artists plowing stuff in that don't know much about subversion). That's what I really need. Unless its per-repository the problem always remains.
>
You may be interested to know that work is being done currently on
"inheritable properties", with amongst others the goal of enabling
"repository dictated configuration" (with svn:ignore or global-ignores
definitely on the radar as a concrete use case). It's too early to
tell how it will turn out concretely, and when it will be finished.
But I'd just thought of letting you know that there may be some
improvement on the horizon.
See this design doc on the wiki:
http://wiki.apache.org/subversion/InheritedProperties
And a dev-thread with lots of discussion (note: it's a long thread,
but contains some interesting discussions and ideas, amongst others
about the ignore property):
http://svn.haxx.se/dev/archive-2012-01/0032.shtml
Paul Burba is currently working on a feature branch to see how the
current design (see wiki) turns out in practice:
http://svn.apache.org/viewvc/subversion/branches/inheritable-props/
--
Johan
RE: default ignores
Posted by James French <Ja...@naturalmotion.com>.
________________________________________
From: Les Mikesell [lesmikesell@gmail.com]
Sent: 17 April 2012 19:34
To: James French
Cc: Subversion Users
Subject: Re: default ignores
On Tue, Apr 17, 2012 at 1:08 PM, James French
<Ja...@naturalmotion.com> wrote:
>
> I would say that it is up to the user to check their commit and if it contains unwanted files then that fact should be visible to them and they can un-add them and set up an ignore if appropriate.
Sorry, but no. A user can't ever un-add something he has committed to
a repository. And it is an unreasonable amount of admin time/work for
the administrator to do it with an svnadmin dump/filter/load cycle.
> Silently failing to add important files I think is worse because you simply don't know that its happened until something goes wrong later.
But you just said the user was supposed to check... It is easy to add
the missed files, but you can't un-add.
> I still believe that svn is a source control system that each user must take responsibility for and configure how they want.
Of course, but defaults should be there for the common case.
> I don't think that config decisions should be taken by the core product. What if a '.a' file means something else on a different platform? Its the arbitrary nature of the excludes I don't like either (ie primarily supports the svn dev's main platform).
That's why it is in a config file, not hardcoded. Make it do whatever
you want. Perhaps the clients should make it easier to see the config
and change it instead of just dropping a normally hidden file
somewhere, but that doesn't make having defaults wrong or less useful.
> One could organise it so the build trees are separate to source trees which completely gets round the problem of accidentally checking in object files... This is what I've got but I'm being penalised because other people mix their build output files in with their source.
There is a worse problem of committing binaries in the mix, especially
if you combine a lot of projects in one repository. How big can the
repository potentially grow and how long do you want to be down when
the time comes to rearrange or clean it up with some dump/load passes?
Or can we just expect hardware speed and capacity to stay ahead of
this problem forever?
--
Les Mikesell
lesmikesell@gmail.com
Fair points. In my first point I did mean pre-commit though. I certainly take your point about irreversible repository bloat though. I think we both agree that a *per-repository* central config system would be great. Then I could have all the lovely ignores on the repositories that contain source code and no ignores on the repositorys that contain SDKs, 3rd party distros, artwork, animation resources etc etc (where it can really hurt when you've got twenty artists plowing stuff in that don't know much about subversion). That's what I really need. Unless its per-repository the problem always remains.
Re: default ignores
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 17, 2012, at 13:34, Les Mikesell wrote:
> On Tue, Apr 17, 2012 at 1:08 PM, James French wrote:
>>
>> I would say that it is up to the user to check their commit and if it contains unwanted files then that fact should be visible to them and they can un-add them and set up an ignore if appropriate.
>
> Sorry, but no. A user can't ever un-add something he has committed to
> a repository. And it is an unreasonable amount of admin time/work for
> the administrator to do it with an svnadmin dump/filter/load cycle.
>
>> Silently failing to add important files I think is worse because you simply don't know that its happened until something goes wrong later.
>
> But you just said the user was supposed to check... It is easy to add
> the missed files, but you can't un-add.
Well, yes you can un-add something:
Add:
$ svn add foo
A foo
Un-add:
$ svn revert foo
Reverted 'foo'
There are several places where this information can be found by Googling "svn unadd".
But if you commit the addition:
$ svn add foo
A foo
$ svn ci foo -m x
Adding foo
Transmitting file data .
Committed revision 1.
Then you're right you can't un-commit that; you'd have to reverse merge, and there'd be a permanent record of it in the repository.
Re: default ignores
Posted by Les Mikesell <le...@gmail.com>.
On Tue, Apr 17, 2012 at 1:08 PM, James French
<Ja...@naturalmotion.com> wrote:
>
> I would say that it is up to the user to check their commit and if it contains unwanted files then that fact should be visible to them and they can un-add them and set up an ignore if appropriate.
Sorry, but no. A user can't ever un-add something he has committed to
a repository. And it is an unreasonable amount of admin time/work for
the administrator to do it with an svnadmin dump/filter/load cycle.
> Silently failing to add important files I think is worse because you simply don't know that its happened until something goes wrong later.
But you just said the user was supposed to check... It is easy to add
the missed files, but you can't un-add.
> I still believe that svn is a source control system that each user must take responsibility for and configure how they want.
Of course, but defaults should be there for the common case.
> I don't think that config decisions should be taken by the core product. What if a '.a' file means something else on a different platform? Its the arbitrary nature of the excludes I don't like either (ie primarily supports the svn dev's main platform).
That's why it is in a config file, not hardcoded. Make it do whatever
you want. Perhaps the clients should make it easier to see the config
and change it instead of just dropping a normally hidden file
somewhere, but that doesn't make having defaults wrong or less useful.
> One could organise it so the build trees are separate to source trees which completely gets round the problem of accidentally checking in object files... This is what I've got but I'm being penalised because other people mix their build output files in with their source.
There is a worse problem of committing binaries in the mix, especially
if you combine a lot of projects in one repository. How big can the
repository potentially grow and how long do you want to be down when
the time comes to rearrange or clean it up with some dump/load passes?
Or can we just expect hardware speed and capacity to stay ahead of
this problem forever?
--
Les Mikesell
lesmikesell@gmail.com
RE: default ignores
Posted by James French <Ja...@naturalmotion.com>.
-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com]
Sent: 17 April 2012 16:57
To: James French
Cc: Subversion Users
Subject: Re: default ignores
On Tue, Apr 17, 2012 at 10:18 AM, James French <Ja...@naturalmotion.com> wrote:
> Hi group,
>
>
>
> Just wanted to have a bit of rant about the default ignores that
> subversion clients have since its cost us so much time and hassle. I
> would like to argue that there should be no default ignores - let the
> client (customer) deal with it.
>
>
>
> The '.a' ignore has particularly hurt us. I've lost count of the times
> that developers have checked in third party SDKs into a 'buildtools'
> type repository only to later find out that a load of .a files were
> missing. I just think its a terrible default.
>
>
>
> The latest thing to hit us was in our build scripts that do drops from
> a perforce repo and create vendor branches etc, which has messed up
> the vendor branches because a script somewhere was not correctly
> countermanding the default ignores.
>
>
>
> This has happened so many times to so many developers over the years
> that I felt I should say something.
>
>
>
> Anyone else agree?
>
>
>
> It would be lovely to be able to set up ignores centrally too without
> relying on individual devs to get it right.
I'd argue that it would be much worse to automatically include common build results for the bazillion commits that don't want them than to have to explicitly mention them in the one commit where you might. I might change my mind about that if subversion ever adds a reasonable way to remove something from a repository, but that seems more and more unlikely.
Defaults aren't ever going to suit everyone. Change them if you don't
like them - that's why you get your own copy. And I'd also argue
that centrally managed default templates for initial user setup would be a good thing, but the user should be able to make the final version suitable for his own purposes. As you say, 'let the client deal with it' - but keep the defaults correct for the common case.
Yeah, I think the best is a centrally manageable but user overridable system.
I would say that it is up to the user to check their commit and if it contains unwanted files then that fact should be visible to them and they can un-add them and set up an ignore if appropriate. Silently failing to add important files I think is worse because you simply don't know that its happened until something goes wrong later. I still believe that svn is a source control system that each user must take responsibility for and configure how they want. I don't think that config decisions should be taken by the core product. What if a '.a' file means something else on a different platform? Its the arbitrary nature of the excludes I don't like either (ie primarily supports the svn dev's main platform).
One could organise it so the build trees are separate to source trees which completely gets round the problem of accidentally checking in object files... This is what I've got but I'm being penalised because other people mix their build output files in with their source.
One last point is that svn is about much more than just source code these days so these default ignores just seem a bit outdated now to me.
Re: default ignores
Posted by Les Mikesell <le...@gmail.com>.
On Tue, Apr 17, 2012 at 10:18 AM, James French
<Ja...@naturalmotion.com> wrote:
> Hi group,
>
>
>
> Just wanted to have a bit of rant about the default ignores that subversion
> clients have since its cost us so much time and hassle. I would like to
> argue that there should be no default ignores – let the client (customer)
> deal with it.
>
>
>
> The ‘.a’ ignore has particularly hurt us. I’ve lost count of the times that
> developers have checked in third party SDKs into a ‘buildtools’ type
> repository only to later find out that a load of .a files were missing. I
> just think its a terrible default.
>
>
>
> The latest thing to hit us was in our build scripts that do drops from a
> perforce repo and create vendor branches etc, which has messed up the vendor
> branches because a script somewhere was not correctly countermanding the
> default ignores.
>
>
>
> This has happened so many times to so many developers over the years that I
> felt I should say something.
>
>
>
> Anyone else agree?
>
>
>
> It would be lovely to be able to set up ignores centrally too without
> relying on individual devs to get it right.
I'd argue that it would be much worse to automatically include common
build results for the bazillion commits that don't want them than to
have to explicitly mention them in the one commit where you might. I
might change my mind about that if subversion ever adds a reasonable
way to remove something from a repository, but that seems more and
more unlikely.
Defaults aren't ever going to suit everyone. Change them if you don't
like them - that's why you get your own copy. And I'd also argue
that centrally managed default templates for initial user setup would
be a good thing, but the user should be able to make the final version
suitable for his own purposes. As you say, 'let the client deal with
it' - but keep the defaults correct for the common case.
--
Les Mikesell
lesmikesell@gmail.com