[OpenSER-Devel] SF.net SVN: openser: [2950] trunk/scripts

[Dan Pascu]

On Saturday 20 October 2007, Dan Pascu wrote:
> Log Message:
> -----------
> Synced generated database schema files with the latest changes in the
> xml schema description files

Regarding this, I think the generated files should not be under version 
control and in the distributed source. It is already a real pain to keep 
them synchronized after the smallest change and also make sure that 
running make proper always returns the tree to its initial state.

Experience shows that autogenerated files that are put under version 
control and distributed with the source are a source of trouble.

We should either remove them from the source (considering that they are 
built again everytime make is run, there is not much need to keep them 
around), or we should stop building them automatically everytime make is 
run and instead make a Makefile entry to build them only on demand.
I would personally prefer the former solution.

Here are just 2 examples of how things can go wrong:

1. If the automatically generated output differs at all between developers 
(assume my xsltproc generates the output a bit different from yours), 
then we will keep overwriting each others version of the files in svn 
everytime we commit something.

2. Assume you want to build a debian package, but need an altered db 
schema. You use dpatch to create a patch that modifies the xml schema and 
build the package. But now, the generated files will also be different 
and after a make proper they won't be returned to the original state 
which means that the debian diff will be broken if you build it again.
Now one could include the modifications to the generated files in the 
debian patch as well (but this is pretty much an ugly hack as it assumes 
that the generated files and their counterparts resulted from patching 
are identical). One shouldn't patch files that are generated as a result 
of the build process. If the generation tool changes the generated output 
at all, the patch will no longer be able to deapply and you will be 
required to remake the debian patch from scratch. At any rate 
maintainability of this situation is very poor and problematic.


-- 
Dan