[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:ignore vs. .cvsignore

From: Steve Greenland <steveg_at_lsli.com>
Date: 2004-12-10 16:32:48 CET

On Fri, Dec 10, 2004 at 01:09:04AM -0700, David Waite wrote:
> So you are suggesting that even though the project has not
> standardized on tools, the repository should be changed to accomidate
> them via an ever-growing array of ignore patterns? It seems if
> you truely are using a wide array of tools, this growth becomes
> unmanageable - you cannot tell which patterns are actually in use, or
> by which people. With the svn:ignore property it is also extremely
> difficult (but certainly not impossible) to track down who added a
> particular entry.

If you development environment is that out-of-control, then the growth
of your svn:ignore property is the least of your worries. What are you
going to do when Joe Smith leaves, and you can no longer build his
part of the project? I'm all for letting people use the tools they're
comfortable with, but mostly what we're talking about here is things
like editor backup files and other spurious stuff, and as the upstream
poster says, if *any* of those conflict with filename patterns that need
to be revision controlled, a localized svn:ignore is not going to help.

So yes, add the patterns to the svn:ignore property. If you can't trust
your developers to add proper log comments ("Added .*~ for emacs backup
files"), then, again, you've got problems that are outside the scope of


"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
                           -- (Stolen from the net)
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 10 16:35:55 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.