commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml-eclipse] Managing generated code in SVN
Date Fri, 11 Jun 2010 02:16:26 GMT
On Thu, Jun 10, 2010 at 10:03 PM, Xun Long Gui <> wrote:
> Hi Rahul,
> Deleting files in SVN server last time is due to my lapse operation,
> sorry for that :-(

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.

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.


> -Gui Xun Long
> On 6/11/10, Rahul Akolkar <> 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]
>> [2]
> --
> Best Regards
> Gui Xun Long (桂训龙)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message