On 11/06/2010, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > 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. >
Can the changes be automated in any way? E.g. editor scripts and the like? If so, then it should be possible to include the scripts in the build process. For example, Commons DBCP uses a scripted approach to fix the sources for different versions of JDBC. If it's not possible to automate the changes, then there needs to be detailed documentation on how to do the changes and what triggers the need to make changes. > -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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
