Hi Rahul, Deleting files in SVN server last time is due to my lapse operation, sorry for that :-( In fact, pattern in (B) is not avaiable, we can not help developers generate all the necessary code by theirselves because we can only generate basic source code and we must change source code by hand to achieve our aim. So, i think we can use pattern A and i will be MORE and MORE careful to maintain SVN workspace.
-Gui Xun Long On 6/11/10, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > 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 > > -- Best Regards Gui Xun Long (桂训龙) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
