-----Original Message----- From: Les Mikesell [mailto:lesmikes...@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 <james.fre...@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.
