tags:

views:

130

answers:

3

At the moment we are checking out our php producation code straight into www. With this we get all the Netbeans meta data and project files that are needed for the site, we have to constantly rm the metadata files from www so they are not accessible from the browser, same goes for all the svn metadata and files too. Is there a way of checking out production code and seperating it from all the files you don't want your users to see?

And, should we be checking in our netbeans projects files in the first place?

+1  A: 

For large projects I generally write a script that checks out the project, removes any extra files (I generally remove any file from the production copy that is unneeded, like sql, setup scripts, etc.), and creates a tarball.

I then deploy the tarball to the staging server. Once we're happy with the condition of the staging server, we deploy the same tarball to the live server. This gives us a chance to clean the tree, test the production copy, AND know that any later changes that might cause problems were are not included when deploying in the production environment.

acrosman
+1  A: 

Committing project files/meta data to a repository is a debatable topic. Purists say a repository is purely for the source code for the application so anyone can check-out the code without relying on any development environment configuration, where as others say it is useful and saves time.

If your team is using the same IDE, and will through-out the life of the project, then I think is can be practical. However, personally, my workplace has always ignored metadata from IDEs like Eclipse and output from the build process.

To address the issue of copying source code straight to production, I suggest using a continuous integration or build server to perform this task. You can then provide a build file to perform the repetitive job of removing unwanted files.

Down the track, you may add another tool to the build chain to automate tasks like testing, syntax checking, code beautification, and deploying to other servers.

abrereton
+1  A: 

Instead of checking out the project, svn export it. That gets rid of any svn metadata. Beyond that, I've gotta agree with acrosman's suggestion: build a script or purge files by hand.

I don't know about NetBeans and how much it auto-generates stuff that you may have included in svn, but in our projects we svn ignore any auto-generated files that are reproducable by the build tools.

Tuminoid