The generated code needs to be better managed with respect to SVN updates. As an example of a pattern we don't want to see, r953073 [1] deletes a number of (previously) generated files. Subsequently, r953075 [2] adds back some of those files after regenerating based on changes to the model. Such an SVN usage pattern isn't very useful because (a) SVN history is wiped clean any time we delete and add back, and (b) the diffs could be much smaller if we don't delete.
So it should be possible to do better. There are atleast two approaches that could be adopted here: (A) Don't delete any files from SVN as done above, just check in the changes after regeneration. This should result in smaller diffs. Need to be careful about not losing license headers and any other round-trip induced problems. (B) Don't check in generated files at all. This means that anyone trying to build the plugin will have to download the correct Eclipse environment and generate code themselves -- so its a little harder for anyone to just try things. But folks will need a suitable environment to run the plugin anyway. What is your preference? Perhaps we can start using the pattern in (A) and see how things go? It'd be good to decide how we want to manage these updates before the next round of such SVN updates. -Rahul [1] http://svn.apache.org/viewvc?view=revision&revision=953073 [2] http://svn.apache.org/viewvc?view=revision&revision=953075 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
