On Thu, Jun 10, 2010 at 10:03 PM, Xun Long Gui <ustbco...@gmail.com> wrote: > Hi Rahul, > > Deleting files in SVN server last time is due to my lapse operation, > sorry for that :-( <snip/>
OK, thanks for clarifying, please be careful not to delete going forward. > 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. > <snap/> Indeed, thats a good point. Speaking of changes to be made by hand, I have a few suggestions (related to naming etc.) -- I will try to find some time this weekend to send an email about that. -Rahul > -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 >> > > > -- > Best Regards > > Gui Xun Long (桂训龙) > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
