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

RE: Feature Proposal: Local Ignores

From: Bob Archer <bob.archer_at_amsi.com>
Date: Mon, 9 Feb 2009 10:54:17 -0500

I assume you know that global-ignores are a client side configuration.
These can be used by each user to set up ignore patters for their
machine. So, you may use Emacs and want to ignore stuff that it creates
while I use Studio and want to ignore its artifacts?

 

I assume by asking for "local" ignores you want something like
global-ignores but have it only apply to a specific working copy? I'm
not sure what advantage this has? Also, it would be quite a pain to
admin it. You can to be copying some ignore file to each WC. Or, you
have to add a path specific ignore to some local config file?

 

________________________________

Example: Some users will use Eclipse, others will use NetBeans, and so
on. These IDEs store additional information in the SVN working copy, and
to prevent SVN from treating them as modifications, currently all these
artefacts have to be masked by svn:ignore. So time after time,
svn:ignore collects more and more of these things. Each new IDE leads to
more svn:ignores -- even when only one programmer in the team is using
this particular tool.

 

It makes no sense to store this information in the repository, since it
is not dependent of the project, but dependent of the programmer or his
machine. So it would make sense to have "local ignores": Things that
will be ignored by the local SVN client, but are not stored in the SVN
repository but solely (a) in the machine's configuration, (b) in the
user's profile, (c) in the local workspace.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1129539

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-09 16:56:01 CET

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.