RE: default ignores

________________________________________
From: Les Mikesell [lesmikesell_at_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
<James.French_at_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_at_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.