Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
David Somers wrote: >> The advantages of commiting the files are clear: Not everyone needs to >> have his/her own set of .cvsignore files to maintain and keep up to >> date > > You should be able to specify that certain files are never to be > committed, and thus can set a policy to that effect... then just setup > the .cvsignore files to enforce that policy. Right. We do that also. >> Disadvantages: If a developer has his own files in the directories, and >> adds them to the ignore file, the .cvsignore file itself shows up as >> modified every time an update is made (which is as annoying as >> non-ignored file showing up). > > What's the problem. Just update the .cvsignore file to get the latest > version. We use "My*" as standard ignored pattern. (Unless of course there's a need for having such files in a project, like maybe 3rd party files. Hasn't happened so far.) Developers don't need to add their own ignore patterns; they just start their own directories and files with "My". > Of course, your real problem is that you probably don't have a clear > idea/policy of what files you want to exclude, and each developer is > simply doing what they think is best... Yes, a clear policy is quite helpful. >> What do you guys do? Do you commit the .cvsignore files or not? > > I commit them. So do we. If there is a need for them, pretty much all developers have the same need. In some cases it is not exactly trivial to find out what needs to go into the repository and what needs to stay out, and there's no reason not to pass that on to everybody else -- through a committed .cvsignore file. Gerhard