On Tue, Apr 17, 2012 at 10:18 AM, James French
<James.French_at_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_at_gmail.com
Received on 2012-04-17 17:57:09 CEST