Automatically set property svn:ignore in generator tasks

as not all developers use SVN it would be better to send an event in the appropriate tasks and then a plugin could provide a listener doing that job

I agree with you. On the other hand, since a big bunch of the developers seems to be using it, I think this could be a useful feature. It would be activated only if your project is a SVN working copy anyway, so people without SVN are not affected.

I disagree with this actually. I add generated files to SVN so that I can compare the generated files between revisions. Or if I upgrade symfony or Doctrine and I regenerate my models, I can then compare the differences in what Doctrine is generating now compared to the old version.

Jon: You're a Doctrine developer, so of course you always want to know what's going on behind the scenes ;-)

But seriously: The modified files should not ever change without the schema being changed (assuming Doctrine is included as external on a fixed revision); if they do, it is a bug in Doctrine. When the schema is changed, it is usually enough to review the schema for changes, so including the generated files should really not be necessary.

Upgrading between different versions of Doctrine is an entire different topic IMO. But since upgrading does happens only once or maybe twice in usual projects (if ever), this should not be a reason to include the generated files on every commit.

I agree with Matthias though, that the best solution would probably be to fire an event that is caught by a handler which does the svn:ignore thing.

I see no reason not to commit your generated files.

When working with a team of developers and svn hooks that synchronise test servers etc. It is *more* tedious to have to make sure everyone rebuilds their model after updating, just in case someone has changed the schema or some other build-task related change.

I like to know that the copy I have generated on my machine is exactly the same as the one in svn (minus cache & log), and thus when checked out by someone else, or deployed to another server, will behave in exactly the same way, without relying on post-update tasks.

I also disagree about upgrading. I've worked on 2 large projects that have spanned almost a year each, and on the latter we actually switched to Doctrine 1.1 half way through, and tend to use the stable branch versions. The base files thus do tend to change.

Finally, when bug fixing errors in your schema, the exception traces often lead back to the base classes. Being able to compare these classes to earlier versions when things go wrong is invaluable, and trying to do so by searching through your schema declaration is time consuming and pointless when the base classes have all the answers.

My 2 cents :)

That is another good point. You should never do a build or anything on your production server. The code should always come from svn and the upgrades should be applied via a patch.

Thank you both for your interesting input. You do have some valid points there.

Strangely I never had the need to compare the generated files between revisions. Instead, developers had to make many useless commits ("rebuilt the model") even if nothing else had changed (although it could be that this was before a tagged version of Doctrine was used in sfDoctrinePlugin). Furthermore, developers have to do build-all-reload anyway to get the database up to date.

Our current solution is a custom project:build task that does all this stuff for us and is simply launched everytime after updating the working copy.

Thank you both for the discussion. You can close this ticket if you want.

The first time rolling out to production you have to create the database, but then after that you don't do any builds or anything to production. Or at least that is what I do. I deploy changes via svn diff/patches and Doctrine migrations. Maybe we could create another ticket to add those events? So that you could implement this as a plugin for your own projects?