Don't Store Generated Resources in CVS

December 12, 2002 3:40 PM

Jeff “!Joe” Duska asks a few questions about CVS and Eclipse. Being a user of both, I thought I'd answer.

As a general rule, I only use CVS to store my primary sources. Anything that is generated or compiled shouldn't go into version control, because it's just noise and gets in the way. It doesn't make that much difference when you're working alone, but in a team environment you'll end up wasting time merging things that could just be deleted and regenerated. So long as you're managing the files that everything is generated from, you're happy.

Eclipse2 has a pretty comprehensive set of tools to manage .cvsignore files, and pretty much the first thing I do when I start a project is to add any build working-directories to them. jar/war/ear files would also be on this list.

Another tip I've found to be useful: When you write your Ant build.xml, externalise all the configurable/system-dependent stuff into a build.properties file. Then add that file to .cvsignore and create a copy called build.properties-example that the user is expected to customise and rename. That way, when you have multiple developers on the project (or in my case, it was a single developer who switched regularly between Windows, OS X and Linux) , each developer can maintain a different build.properties, which won't be clobbered by CVS every time you integrate.

Updates:

I often put library jar files in CVS, because they rarely change and it's as good a place to put them as any. I probably shouldn't, and I would never do this on a distributed project even if the licenses allowed, because it's really annoying to people who already have the libraries, and who are trying to do a checkout over a modem. (I still use a 56k modem at home).

BaristaLog1 doesn't like my build.properties approach because it causes problems tracking down build issues, and it makes it harder to do an automated build.

Russell Beattie suggests an alternative approach to the build.properties thing: each developer sets an $ANT_USER environment variable, and the location-dependent build properties go in $ANT_USER.properties. (Read the comments for that post, too. Matt Raible has a cool solution building a search path from ${user.home})

Russell also notes that if your project is big enough that it takes ages to build, that's when you need jar files in CVS. My gut reaction is that the necessity to put your built project in source-control is a CodeSmell, and may be an indication that the project needs to be reorganised somehow, but I'll need to sit on that thought for a while before I commit to it.

1 I'm tempted to go on a crusade in javablogland to make sure everybody has their name, or at least a plausible alias on the front page of their blog. Blog-linking is a form of conversation, and I feel far more comfortable having conversations with people, rather than page titles. (See also: RealNamesPlease).

Previously: Why Java will not get Macros

Next: Why Hibernate Rocks