commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
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 <ustbcoder@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.akolkar@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message