Re: svn commit: r886743 [1/4] - in /ofbiz/branches/addbirt: applications/accounting/webapp/accounting/WEB-INF/ applications/accounting/webapp/accounting/WEB-INF/actions/payment/ applications/accounting/webapp/accounting/payment/report/ applications/account...

[Scott Gray-2]

Hi Hans,

When all of this comes across to the trunk could please consider  
separating it into at least two commits, one for the integration and  
another for all this other stuff.  It'll make the commits a little  
easier to read especially when people are looking at the commit history.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 4/12/2009, at 12:12 AM, [hidden email] wrote:

> Author: hansbak
> Date: Thu Dec  3 11:12:50 2009
> New Revision: 886743
>
> URL: http://svn.apache.org/viewvc?rev=886743&view=rev
> Log:
> some example Birt reports with selection forms in accounting ->  
> payment and order -> reports
>
> Added:
>    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> WEB-INF/actions/payment/PaymentReport.groovy   (with props)
>    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> payment/report/
>    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> payment/report/PaymentReport.rptdesign
>    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/WEB-INF/
> actions/reports/OrderByChannel.groovy   (with props)
>    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
> OrderByReferrer.rptdesign
>    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
> OrderDiscountCodeReport.rptdesign
>    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
> OrdersByChannel.rptdesign
>    ofbiz/branches/addbirt/applications/product/script/org/ofbiz/
> product/olap/FactServices.xml   (with props)
>    ofbiz/branches/addbirt/applications/product/webapp/facility/WEB-
> INF/actions/inventory/InventoryItemReport.groovy   (with props)
>    ofbiz/branches/addbirt/applications/product/webapp/facility/
> inventory/report/
>    ofbiz/branches/addbirt/applications/product/webapp/facility/
> inventory/report/InventoryReport.rptdesign
> Modified:
>    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> WEB-INF/controller.xml
>    ofbiz/branches/addbirt/applications/accounting/widget/
> AccountingMenus.xml
>    ofbiz/branches/addbirt/applications/accounting/widget/
> CommonScreens.xml
>    ofbiz/branches/addbirt/applications/accounting/widget/
> PaymentForms.xml
>    ofbiz/branches/addbirt/applications/accounting/widget/
> PaymentScreens.xml
>    ofbiz/branches/addbirt/applications/order/data/OrderPortletData.xml
>    ofbiz/branches/addbirt/applications/order/entitydef/
> entitygroup_olap.xml
>    ofbiz/branches/addbirt/applications/order/entitydef/
> entitymodel_olap.xml
>    ofbiz/branches/addbirt/applications/order/script/org/ofbiz/order/
> olap/FactServices.xml
>    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/WEB-INF/
> controller.xml
>    ofbiz/branches/addbirt/applications/order/widget/ordermgr/
> ReportForms.xml
>    ofbiz/branches/addbirt/applications/order/widget/ordermgr/
> ReportScreens.xml
>    ofbiz/branches/addbirt/applications/product/entitydef/
> entitygroup_olap.xml
>    ofbiz/branches/addbirt/applications/product/entitydef/
> entitymodel_olap.xml
>    ofbiz/branches/addbirt/applications/product/servicedef/
> services_olap.xml
>    ofbiz/branches/addbirt/applications/product/webapp/facility/WEB-
> INF/controller.xml
>    ofbiz/branches/addbirt/applications/product/widget/facility/
> FacilityForms.xml
>    ofbiz/branches/addbirt/applications/product/widget/facility/
> FacilityScreens.xml
>    ofbiz/branches/addbirt/applications/product/widget/facility/
> ReportScreens.xml
>    ofbiz/branches/addbirt/framework/bi/script/org/ofbiz/bi/
> DimensionServices.xml

[hans_bakker]

I am waiting for your first positive comment.....

Did you look at the New Revision: 886087 where we solved your last
concerns?

If you want to review these commits why not check them in the birt
branch...there they are separated.

Regards,
Hans

On Fri, 2009-12-04 at 00:27 +1300, Scott Gray wrote:

> Hi Hans,
>
> When all of this comes across to the trunk could please consider  
> separating it into at least two commits, one for the integration and  
> another for all this other stuff.  It'll make the commits a little  
> easier to read especially when people are looking at the commit history.
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 4/12/2009, at 12:12 AM, [hidden email] wrote:
>
> > Author: hansbak
> > Date: Thu Dec  3 11:12:50 2009
> > New Revision: 886743
> >
> > URL: http://svn.apache.org/viewvc?rev=886743&view=rev
> > Log:
> > some example Birt reports with selection forms in accounting ->  
> > payment and order -> reports
> >
> > Added:
> >    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> > WEB-INF/actions/payment/PaymentReport.groovy   (with props)
> >    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> > payment/report/
> >    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> > payment/report/PaymentReport.rptdesign
> >    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/WEB-INF/
> > actions/reports/OrderByChannel.groovy   (with props)
> >    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
> > OrderByReferrer.rptdesign
> >    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
> > OrderDiscountCodeReport.rptdesign
> >    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
> > OrdersByChannel.rptdesign
> >    ofbiz/branches/addbirt/applications/product/script/org/ofbiz/
> > product/olap/FactServices.xml   (with props)
> >    ofbiz/branches/addbirt/applications/product/webapp/facility/WEB-
> > INF/actions/inventory/InventoryItemReport.groovy   (with props)
> >    ofbiz/branches/addbirt/applications/product/webapp/facility/
> > inventory/report/
> >    ofbiz/branches/addbirt/applications/product/webapp/facility/
> > inventory/report/InventoryReport.rptdesign
> > Modified:
> >    ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
> > WEB-INF/controller.xml
> >    ofbiz/branches/addbirt/applications/accounting/widget/
> > AccountingMenus.xml
> >    ofbiz/branches/addbirt/applications/accounting/widget/
> > CommonScreens.xml
> >    ofbiz/branches/addbirt/applications/accounting/widget/
> > PaymentForms.xml
> >    ofbiz/branches/addbirt/applications/accounting/widget/
> > PaymentScreens.xml
> >    ofbiz/branches/addbirt/applications/order/data/OrderPortletData.xml
> >    ofbiz/branches/addbirt/applications/order/entitydef/
> > entitygroup_olap.xml
> >    ofbiz/branches/addbirt/applications/order/entitydef/
> > entitymodel_olap.xml
> >    ofbiz/branches/addbirt/applications/order/script/org/ofbiz/order/
> > olap/FactServices.xml
> >    ofbiz/branches/addbirt/applications/order/webapp/ordermgr/WEB-INF/
> > controller.xml
> >    ofbiz/branches/addbirt/applications/order/widget/ordermgr/
> > ReportForms.xml
> >    ofbiz/branches/addbirt/applications/order/widget/ordermgr/
> > ReportScreens.xml
> >    ofbiz/branches/addbirt/applications/product/entitydef/
> > entitygroup_olap.xml
> >    ofbiz/branches/addbirt/applications/product/entitydef/
> > entitymodel_olap.xml
> >    ofbiz/branches/addbirt/applications/product/servicedef/
> > services_olap.xml
> >    ofbiz/branches/addbirt/applications/product/webapp/facility/WEB-
> > INF/controller.xml
> >    ofbiz/branches/addbirt/applications/product/widget/facility/
> > FacilityForms.xml
> >    ofbiz/branches/addbirt/applications/product/widget/facility/
> > FacilityScreens.xml
> >    ofbiz/branches/addbirt/applications/product/widget/facility/
> > ReportScreens.xml
> >    ofbiz/branches/addbirt/framework/bi/script/org/ofbiz/bi/
> > DimensionServices.xml
>

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Scott Gray-2]

On 4/12/2009, at 1:05 AM, Hans Bakker wrote:

> I am waiting for your first positive comment.....

All my comments are positive (or at least neutral), it's just your  
perception of them that is negative.

> Did you look at the New Revision: 886087 where we solved your last
> concerns?

Briefly and I liked the approach, I'll take another pass over the  
whole thing on the weekend.

> If you want to review these commits why not check them in the birt
> branch...there they are separated.

I'm not so concerned about myself but more for others and in  
particular people looking at the commit history in the future.
The integration and the examples are completely different subject  
matters are should be treated as such when committing to the trunk  
regardless of how they've been committed to the branch.

> Regards,
> Hans
>
> On Fri, 2009-12-04 at 00:27 +1300, Scott Gray wrote:
>> Hi Hans,
>>
>> When all of this comes across to the trunk could please consider
>> separating it into at least two commits, one for the integration and
>> another for all this other stuff.  It'll make the commits a little
>> easier to read especially when people are looking at the commit  
>> history.
>>
>> Thanks
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 4/12/2009, at 12:12 AM, [hidden email] wrote:
>>
>>> Author: hansbak
>>> Date: Thu Dec  3 11:12:50 2009
>>> New Revision: 886743
>>>
>>> URL: http://svn.apache.org/viewvc?rev=886743&view=rev
>>> Log:
>>> some example Birt reports with selection forms in accounting ->
>>> payment and order -> reports
>>>
>>> Added:
>>>   ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
>>> WEB-INF/actions/payment/PaymentReport.groovy   (with props)
>>>   ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
>>> payment/report/
>>>   ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
>>> payment/report/PaymentReport.rptdesign
>>>   ofbiz/branches/addbirt/applications/order/webapp/ordermgr/WEB-INF/
>>> actions/reports/OrderByChannel.groovy   (with props)
>>>   ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
>>> OrderByReferrer.rptdesign
>>>   ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
>>> OrderDiscountCodeReport.rptdesign
>>>   ofbiz/branches/addbirt/applications/order/webapp/ordermgr/reports/
>>> OrdersByChannel.rptdesign
>>>   ofbiz/branches/addbirt/applications/product/script/org/ofbiz/
>>> product/olap/FactServices.xml   (with props)
>>>   ofbiz/branches/addbirt/applications/product/webapp/facility/WEB-
>>> INF/actions/inventory/InventoryItemReport.groovy   (with props)
>>>   ofbiz/branches/addbirt/applications/product/webapp/facility/
>>> inventory/report/
>>>   ofbiz/branches/addbirt/applications/product/webapp/facility/
>>> inventory/report/InventoryReport.rptdesign
>>> Modified:
>>>   ofbiz/branches/addbirt/applications/accounting/webapp/accounting/
>>> WEB-INF/controller.xml
>>>   ofbiz/branches/addbirt/applications/accounting/widget/
>>> AccountingMenus.xml
>>>   ofbiz/branches/addbirt/applications/accounting/widget/
>>> CommonScreens.xml
>>>   ofbiz/branches/addbirt/applications/accounting/widget/
>>> PaymentForms.xml
>>>   ofbiz/branches/addbirt/applications/accounting/widget/
>>> PaymentScreens.xml
>>>   ofbiz/branches/addbirt/applications/order/data/
>>> OrderPortletData.xml
>>>   ofbiz/branches/addbirt/applications/order/entitydef/
>>> entitygroup_olap.xml
>>>   ofbiz/branches/addbirt/applications/order/entitydef/
>>> entitymodel_olap.xml
>>>   ofbiz/branches/addbirt/applications/order/script/org/ofbiz/order/
>>> olap/FactServices.xml
>>>   ofbiz/branches/addbirt/applications/order/webapp/ordermgr/WEB-INF/
>>> controller.xml
>>>   ofbiz/branches/addbirt/applications/order/widget/ordermgr/
>>> ReportForms.xml
>>>   ofbiz/branches/addbirt/applications/order/widget/ordermgr/
>>> ReportScreens.xml
>>>   ofbiz/branches/addbirt/applications/product/entitydef/
>>> entitygroup_olap.xml
>>>   ofbiz/branches/addbirt/applications/product/entitydef/
>>> entitymodel_olap.xml
>>>   ofbiz/branches/addbirt/applications/product/servicedef/
>>> services_olap.xml
>>>   ofbiz/branches/addbirt/applications/product/webapp/facility/WEB-
>>> INF/controller.xml
>>>   ofbiz/branches/addbirt/applications/product/widget/facility/
>>> FacilityForms.xml
>>>   ofbiz/branches/addbirt/applications/product/widget/facility/
>>> FacilityScreens.xml
>>>   ofbiz/branches/addbirt/applications/product/widget/facility/
>>> ReportScreens.xml
>>>   ofbiz/branches/addbirt/framework/bi/script/org/ofbiz/bi/
>>> DimensionServices.xml
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>

[David E. Jones-2]

On Dec 3, 2009, at 5:18 AM, Scott Gray wrote:

> On 4/12/2009, at 1:05 AM, Hans Bakker wrote:
>
>> If you want to review these commits why not check them in the birt
>> branch...there they are separated.
>
> I'm not so concerned about myself but more for others and in particular people looking at the commit history in the future.
> The integration and the examples are completely different subject matters are should be treated as such when committing to the trunk regardless of how they've been committed to the branch.

How would one separate them when committing them to the trunk?

Typically merging a branch with the trunk involves a single commit in order to keep it simple. It doesn't have to be that way, but it nice to simply say branch rev X was merged into the trunk at trunk rev Y.

-David

[Adam Heath-2]

Scott Gray wrote:
> Hi Hans,
>
> When all of this comes across to the trunk could please consider
> separating it into at least two commits, one for the integration and
> another for all this other stuff.  It'll make the commits a little
> easier to read especially when people are looking at the commit history.

As I've said countless times, git makes this easier.  You'd maintain a
branch(local clone with maybe a separate local branch).  Then, a
series of commits in that branch.  Git supports history rewriting, so
you can do things like push/pop commits and edit them.
guilt(git+quilt) can help, there are also other tools that are similiar.

[Adam Heath-2]

Hans Bakker wrote:
> I am waiting for your first positive comment.....

The fact that people are commenting about your birt work is a good
thing.  It shows that there is interest, and that people would like to
see it in the project.

[Adam Heath-2]

David E Jones wrote:

> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote:
>
>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote:
>>
>>> If you want to review these commits why not check them in the birt
>>> branch...there they are separated.
>> I'm not so concerned about myself but more for others and in particular people looking at the commit history in the future.
>> The integration and the examples are completely different subject matters are should be treated as such when committing to the trunk regardless of how they've been committed to the branch.
>
> How would one separate them when committing them to the trunk?
>
> Typically merging a branch with the trunk involves a single commit in order to keep it simple. It doesn't have to be that way, but it nice to simply say branch rev X was merged into the trunk at trunk rev Y.

You may not have noticed, but I've done several bulk commits with
git+svn.  I'll do a whole bunch of work, then when everything is
finished, and I've doing various testing at each individual point in
the chain, I'll flood svn with several commits back to back.  You'll
see all the individual, *small* changes, as I first fix bugs, rename
methods, make things private from public, then finally remove whole
swaths of code.  Look at the UtilCache stuff I did recently, where I
made the constructor(s) private.

[Adam Heath-2]

Adam Heath wrote:

> David E Jones wrote:
>> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote:
>>
>>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote:
>>>
>>>> If you want to review these commits why not check them in the birt
>>>> branch...there they are separated.
>>> I'm not so concerned about myself but more for others and in particular people looking at the commit history in the future.
>>> The integration and the examples are completely different subject matters are should be treated as such when committing to the trunk regardless of how they've been committed to the branch.
>> How would one separate them when committing them to the trunk?
>>
>> Typically merging a branch with the trunk involves a single commit in order to keep it simple. It doesn't have to be that way, but it nice to simply say branch rev X was merged into the trunk at trunk rev Y.
>
> You may not have noticed, but I've done several bulk commits with
> git+svn.  I'll do a whole bunch of work, then when everything is
> finished, and I've doing various testing at each individual point in
> the chain, I'll flood svn with several commits back to back.  You'll
> see all the individual, *small* changes, as I first fix bugs, rename
> methods, make things private from public, then finally remove whole
> swaths of code.  Look at the UtilCache stuff I did recently, where I
> made the constructor(s) private.

responding to myself

Doing it this way makes me feel more comfortable, because I have
verified that things work at the end, before anyone else has a chance
to find out I screwed something up.

[David E. Jones-2]

On Dec 3, 2009, at 11:36 AM, Adam Heath wrote:

> David E Jones wrote:
>> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote:
>>
>>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote:
>>>
>>>> If you want to review these commits why not check them in the birt
>>>> branch...there they are separated.
>>> I'm not so concerned about myself but more for others and in particular people looking at the commit history in the future.
>>> The integration and the examples are completely different subject matters are should be treated as such when committing to the trunk regardless of how they've been committed to the branch.
>>
>> How would one separate them when committing them to the trunk?
>>
>> Typically merging a branch with the trunk involves a single commit in order to keep it simple. It doesn't have to be that way, but it nice to simply say branch rev X was merged into the trunk at trunk rev Y.
>
> You may not have noticed, but I've done several bulk commits with
> git+svn.  I'll do a whole bunch of work, then when everything is
> finished, and I've doing various testing at each individual point in
> the chain, I'll flood svn with several commits back to back.  You'll
> see all the individual, *small* changes, as I first fix bugs, rename
> methods, make things private from public, then finally remove whole
> swaths of code.  Look at the UtilCache stuff I did recently, where I
> made the constructor(s) private.

That's great Adam, but not how branches are generally done. There is already a revision history in the branch, so why duplicate that in the trunk instead of doing a more traditional, easy, and clean merge?

In fact, I like branches better if you want to collaborate with others. If you don't it doesn't really matter I suppose.

-David

[Adam Heath-2]

David E Jones wrote:

> On Dec 3, 2009, at 11:36 AM, Adam Heath wrote:
>
>> David E Jones wrote:
>>> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote:
>>>
>>>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote:
>>>>
>>>>> If you want to review these commits why not check them in the birt
>>>>> branch...there they are separated.
>>>> I'm not so concerned about myself but more for others and in particular people looking at the commit history in the future.
>>>> The integration and the examples are completely different subject matters are should be treated as such when committing to the trunk regardless of how they've been committed to the branch.
>>> How would one separate them when committing them to the trunk?
>>>
>>> Typically merging a branch with the trunk involves a single commit in order to keep it simple. It doesn't have to be that way, but it nice to simply say branch rev X was merged into the trunk at trunk rev Y.
>> You may not have noticed, but I've done several bulk commits with
>> git+svn.  I'll do a whole bunch of work, then when everything is
>> finished, and I've doing various testing at each individual point in
>> the chain, I'll flood svn with several commits back to back.  You'll
>> see all the individual, *small* changes, as I first fix bugs, rename
>> methods, make things private from public, then finally remove whole
>> swaths of code.  Look at the UtilCache stuff I did recently, where I
>> made the constructor(s) private.
>
> That's great Adam, but not how branches are generally done. There is already a revision history in the branch, so why duplicate that in the trunk instead of doing a more traditional, easy, and clean merge?
>
> In fact, I like branches better if you want to collaborate with others. If you don't it doesn't really matter I suppose.

If you consider that I was doing it with git, which is done offline,
then my explanation makes sense.

Scott's suggestion about keeping *trunk* history nice and neat is a
valid point.  Git allows that to happen in a much easier fashion.

And with git, you can still publish your local changes, it just takes
a bit of configuration.  Not to mention the fact that you can work
*completely* offline, even doing stuff in plains, trains, and
automobiles, saving commit history, instead of waiting for a network
connection.

>
> -David
>

[Adam Heath-2]

Adam Heath wrote:
> Hans Bakker wrote:
>> I am waiting for your first positive comment.....
>
> The fact that people are commenting about your birt work is a good
> thing.  It shows that there is interest, and that people would like to
> see it in the project.

Brainfood is actively using birt in customer solutions, including some
of Hans' work.  I would be interested in taking the responsibility for
integrating this into trunk when it is all said and done.

I would be doing several small commits when this is all done.  I'll be
using git to make this possible.  When the addbirt branch is actually
really ready, I'll take the branch in it's entirety as *one* git
commit, then using git's history rewriting features split the single
commit into however many separate commits are needed.

I personally don't have the time to actively investigate how birt
works, or how to integrate it.  However, I will put on a hat to finish
this integration when it is all said and done.

[Scott Gray-2]

On 4/12/2009, at 5:59 AM, David E Jones wrote:

>
> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote:
>
>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote:
>>
>>> If you want to review these commits why not check them in the birt
>>> branch...there they are separated.
>>
>> I'm not so concerned about myself but more for others and in  
>> particular people looking at the commit history in the future.
>> The integration and the examples are completely different subject  
>> matters are should be treated as such when committing to the trunk  
>> regardless of how they've been committed to the branch.
>
> How would one separate them when committing them to the trunk?

Quite easily, you don't have to merge the entire thing in one hit.  

You can easily merge individual folder or files.

> Typically merging a branch with the trunk involves a single commit  
> in order to keep it simple. It doesn't have to be that way, but it  
> nice to simply say branch rev X was merged into the trunk at trunk  
> rev Y.

I guess I prefer having a couple of simpler commits over having a nice  
commit message.  But then it isn't too much more trouble to say branch  
rev X was merged into the trunk at trunk rev Y and Z.

With that said, I don't want to get into a big debate over it, I only  
suggested it because I believe it is easy enough to do and would make  
for a better commit history.  If you and Hans don't think it is of any  
value that's fine, I'm not going to push for it.

[Scott Gray-2]

On 4/12/2009, at 7:32 AM, Adam Heath wrote:

> Scott Gray wrote:
>> Hi Hans,
>>
>> When all of this comes across to the trunk could please consider
>> separating it into at least two commits, one for the integration and
>> another for all this other stuff.  It'll make the commits a little
>> easier to read especially when people are looking at the commit  
>> history.
>
> As I've said countless times, git makes this easier.  You'd maintain a
> branch(local clone with maybe a separate local branch).  Then, a
> series of commits in that branch.  Git supports history rewriting, so
> you can do things like push/pop commits and edit them.
> guilt(git+quilt) can help, there are also other tools that are  
> similiar.

I'm a couple of days into using git locally and I like it so far.
But there are a couple of things people should be aware of when  
considering the switch:
- The initial checkout takes a long time (+9 hours on my machine)  
although it only ever has to be done once
- The learning curve is steeper than with svn
- The workflows are quite different from svn so be prepared to change  
the way you work
- Setup on OS X can be a pain (you need XCode tools installed to use  
the git-svn bridge and if you don't have your OS X install DVD handy  
it's a 1GB download)
- GUI support is limited (e.g. the Eclipse plugin is at v0.6)

[Joe Eckard]

On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:

> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>
>> Scott Gray wrote:
>>> Hi Hans,
>>>
>>> When all of this comes across to the trunk could please consider
>>> separating it into at least two commits, one for the integration and
>>> another for all this other stuff.  It'll make the commits a little
>>> easier to read especially when people are looking at the commit  
>>> history.
>>
>> As I've said countless times, git makes this easier.  You'd  
>> maintain a
>> branch(local clone with maybe a separate local branch).  Then, a
>> series of commits in that branch.  Git supports history rewriting, so
>> you can do things like push/pop commits and edit them.
>> guilt(git+quilt) can help, there are also other tools that are  
>> similiar.
>
> I'm a couple of days into using git locally and I like it so far.
> But there are a couple of things people should be aware of when  
> considering the switch:
> - The initial checkout takes a long time (+9 hours on my machine)  
> although it only ever has to be done once

You can pick the revision to start your tracking at with the -r switch  
to avoid loading the entire project history.

> - The learning curve is steeper than with svn
> - The workflows are quite different from svn so be prepared to  
> change the way you work
> - Setup on OS X can be a pain (you need XCode tools installed to use  
> the git-svn bridge and if you don't have your OS X install DVD handy  
> it's a 1GB download)
> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)

Have you checked out "git gui" and GitX? http://gitx.frim.nl/

I use git from the command line, so I'm not sure how well the "git  
gui" UI works, but GitX is pretty neat.

[Anil Patel-3]

Scott, Have your tried IntelliJ,

More recent release of IntelliJ Community edition has support for Git. In fact recently I have switched to using IntelliJ and I like it.
 
Thanks and Regards
Anil Patel
HotWax Media Inc
http://www.hotwaxmedia.com/apache-ofbiz-blog/ofbiz-tutorial-custom-components-in-ofbiz/

On Dec 3, 2009, at 3:12 PM, Joe Eckard wrote:

>
> On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:
>
>> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>>
>>> Scott Gray wrote:
>>>> Hi Hans,
>>>>
>>>> When all of this comes across to the trunk could please consider
>>>> separating it into at least two commits, one for the integration and
>>>> another for all this other stuff.  It'll make the commits a little
>>>> easier to read especially when people are looking at the commit history.
>>>
>>> As I've said countless times, git makes this easier.  You'd maintain a
>>> branch(local clone with maybe a separate local branch).  Then, a
>>> series of commits in that branch.  Git supports history rewriting, so
>>> you can do things like push/pop commits and edit them.
>>> guilt(git+quilt) can help, there are also other tools that are similiar.
>>
>> I'm a couple of days into using git locally and I like it so far.
>> But there are a couple of things people should be aware of when considering the switch:
>> - The initial checkout takes a long time (+9 hours on my machine) although it only ever has to be done once
>
> You can pick the revision to start your tracking at with the -r switch to avoid loading the entire project history.
>
>> - The learning curve is steeper than with svn
>> - The workflows are quite different from svn so be prepared to change the way you work
>> - Setup on OS X can be a pain (you need XCode tools installed to use the git-svn bridge and if you don't have your OS X install DVD handy it's a 1GB download)
>> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)
>
> Have you checked out "git gui" and GitX? http://gitx.frim.nl/
>
> I use git from the command line, so I'm not sure how well the "git gui" UI works, but GitX is pretty neat.

[Scott Gray-2]

On 4/12/2009, at 9:12 AM, Joe Eckard wrote:

>
> On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:
>
>> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>>
>>> Scott Gray wrote:
>>>> Hi Hans,
>>>>
>>>> When all of this comes across to the trunk could please consider
>>>> separating it into at least two commits, one for the integration  
>>>> and
>>>> another for all this other stuff.  It'll make the commits a little
>>>> easier to read especially when people are looking at the commit  
>>>> history.
>>>
>>> As I've said countless times, git makes this easier.  You'd  
>>> maintain a
>>> branch(local clone with maybe a separate local branch).  Then, a
>>> series of commits in that branch.  Git supports history rewriting,  
>>> so
>>> you can do things like push/pop commits and edit them.
>>> guilt(git+quilt) can help, there are also other tools that are  
>>> similiar.
>>
>> I'm a couple of days into using git locally and I like it so far.
>> But there are a couple of things people should be aware of when  
>> considering the switch:
>> - The initial checkout takes a long time (+9 hours on my machine)  
>> although it only ever has to be done once
>
> You can pick the revision to start your tracking at with the -r  
> switch to avoid loading the entire project history.

Thanks for the tip, I would probably still load the entire history  

anyway since you only have to do it once and it's handy to have when  
your offline.

>
>> - The learning curve is steeper than with svn
>> - The workflows are quite different from svn so be prepared to  
>> change the way you work
>> - Setup on OS X can be a pain (you need XCode tools installed to  
>> use the git-svn bridge and if you don't have your OS X install DVD  
>> handy it's a 1GB download)
>> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)
>
> Have you checked out "git gui" and GitX? http://gitx.frim.nl/
>
> I use git from the command line, so I'm not sure how well the "git  
> gui" UI works, but GitX is pretty neat.

I haven't had a good look around yet but I'll definitely give GitX a  
look.  git gui doesn't work OOTB on Leopard:
dyld: Library not loaded: /Library/Frameworks/Tk.framework/Versions/
8.5/Tk
   Referenced from: /usr/local/git/share/git-gui/lib/Git Gui.app/
Contents/MacOS/Wish
   Reason: image not found
error: git-gui died of signal 5

Apparently it can be solved by upgrading the Tk.framework but I  
haven't gotten around to doing it yet.

Thanks for the pointers!

[Scott Gray-2]

I did try it very briefly a few years back but I'm so used to Eclipse  
now that I'd be pretty reluctant to switch.  I will download it at  
some point though and take another look, thanks for the info.

Regards
Scott

On 4/12/2009, at 9:34 AM, Anil Patel wrote:

> Scott, Have your tried IntelliJ,
>
> More recent release of IntelliJ Community edition has support for  
> Git. In fact recently I have switched to using IntelliJ and I like it.
>
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
> http://www.hotwaxmedia.com/apache-ofbiz-blog/ofbiz-tutorial-custom-components-in-ofbiz/
>
> On Dec 3, 2009, at 3:12 PM, Joe Eckard wrote:
>
>>
>> On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:
>>
>>> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>>>
>>>> Scott Gray wrote:
>>>>> Hi Hans,
>>>>>
>>>>> When all of this comes across to the trunk could please consider
>>>>> separating it into at least two commits, one for the integration  
>>>>> and
>>>>> another for all this other stuff.  It'll make the commits a little
>>>>> easier to read especially when people are looking at the commit  
>>>>> history.
>>>>
>>>> As I've said countless times, git makes this easier.  You'd  
>>>> maintain a
>>>> branch(local clone with maybe a separate local branch).  Then, a
>>>> series of commits in that branch.  Git supports history  
>>>> rewriting, so
>>>> you can do things like push/pop commits and edit them.
>>>> guilt(git+quilt) can help, there are also other tools that are  
>>>> similiar.
>>>
>>> I'm a couple of days into using git locally and I like it so far.
>>> But there are a couple of things people should be aware of when  
>>> considering the switch:
>>> - The initial checkout takes a long time (+9 hours on my machine)  
>>> although it only ever has to be done once
>>
>> You can pick the revision to start your tracking at with the -r  
>> switch to avoid loading the entire project history.
>>
>>> - The learning curve is steeper than with svn
>>> - The workflows are quite different from svn so be prepared to  
>>> change the way you work
>>> - Setup on OS X can be a pain (you need XCode tools installed to  
>>> use the git-svn bridge and if you don't have your OS X install DVD  
>>> handy it's a 1GB download)
>>> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)
>>
>> Have you checked out "git gui" and GitX? http://gitx.frim.nl/
>>
>> I use git from the command line, so I'm not sure how well the "git  
>> gui" UI works, but GitX is pretty neat.
>

[Scott Gray-2]

BTW if memory serves you should be able to get a license for the full  
version for free via their open source program.

Regards
Scott

On 4/12/2009, at 9:49 AM, Scott Gray wrote:

> I did try it very briefly a few years back but I'm so used to  
> Eclipse now that I'd be pretty reluctant to switch.  I will download  
> it at some point though and take another look, thanks for the info.
>
> Regards
> Scott
>
> On 4/12/2009, at 9:34 AM, Anil Patel wrote:
>
>> Scott, Have your tried IntelliJ,
>>
>> More recent release of IntelliJ Community edition has support for  
>> Git. In fact recently I have switched to using IntelliJ and I like  
>> it.
>>
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> http://www.hotwaxmedia.com/apache-ofbiz-blog/ofbiz-tutorial-custom-components-in-ofbiz/
>>
>> On Dec 3, 2009, at 3:12 PM, Joe Eckard wrote:
>>
>>>
>>> On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:
>>>
>>>> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>>>>
>>>>> Scott Gray wrote:
>>>>>> Hi Hans,
>>>>>>
>>>>>> When all of this comes across to the trunk could please consider
>>>>>> separating it into at least two commits, one for the  
>>>>>> integration and
>>>>>> another for all this other stuff.  It'll make the commits a  
>>>>>> little
>>>>>> easier to read especially when people are looking at the commit  
>>>>>> history.
>>>>>
>>>>> As I've said countless times, git makes this easier.  You'd  
>>>>> maintain a
>>>>> branch(local clone with maybe a separate local branch).  Then, a
>>>>> series of commits in that branch.  Git supports history  
>>>>> rewriting, so
>>>>> you can do things like push/pop commits and edit them.
>>>>> guilt(git+quilt) can help, there are also other tools that are  
>>>>> similiar.
>>>>
>>>> I'm a couple of days into using git locally and I like it so far.
>>>> But there are a couple of things people should be aware of when  
>>>> considering the switch:
>>>> - The initial checkout takes a long time (+9 hours on my machine)  
>>>> although it only ever has to be done once
>>>
>>> You can pick the revision to start your tracking at with the -r  
>>> switch to avoid loading the entire project history.
>>>
>>>> - The learning curve is steeper than with svn
>>>> - The workflows are quite different from svn so be prepared to  
>>>> change the way you work
>>>> - Setup on OS X can be a pain (you need XCode tools installed to  
>>>> use the git-svn bridge and if you don't have your OS X install  
>>>> DVD handy it's a 1GB download)
>>>> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)
>>>
>>> Have you checked out "git gui" and GitX? http://gitx.frim.nl/
>>>
>>> I use git from the command line, so I'm not sure how well the "git  
>>> gui" UI works, but GitX is pretty neat.
>>
>

[Joe Eckard]

Yes, you just have to fill out their questionnaire and if approved you  
will get a license valid for one year (which must be renewed).

-Joe

On Dec 3, 2009, at 3:55 PM, Scott Gray wrote:

> BTW if memory serves you should be able to get a license for the  
> full version for free via their open source program.
>
> Regards
> Scott
>
> On 4/12/2009, at 9:49 AM, Scott Gray wrote:
>
>> I did try it very briefly a few years back but I'm so used to  
>> Eclipse now that I'd be pretty reluctant to switch.  I will  
>> download it at some point though and take another look, thanks for  
>> the info.
>>
>> Regards
>> Scott
>>
>> On 4/12/2009, at 9:34 AM, Anil Patel wrote:
>>
>>> Scott, Have your tried IntelliJ,
>>>
>>> More recent release of IntelliJ Community edition has support for  
>>> Git. In fact recently I have switched to using IntelliJ and I like  
>>> it.
>>>
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> http://www.hotwaxmedia.com/apache-ofbiz-blog/ofbiz-tutorial-custom-components-in-ofbiz/
>>>
>>> On Dec 3, 2009, at 3:12 PM, Joe Eckard wrote:
>>>
>>>>
>>>> On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:
>>>>
>>>>> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>>>>>
>>>>>> Scott Gray wrote:
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> When all of this comes across to the trunk could please consider
>>>>>>> separating it into at least two commits, one for the  
>>>>>>> integration and
>>>>>>> another for all this other stuff.  It'll make the commits a  
>>>>>>> little
>>>>>>> easier to read especially when people are looking at the  
>>>>>>> commit history.
>>>>>>
>>>>>> As I've said countless times, git makes this easier.  You'd  
>>>>>> maintain a
>>>>>> branch(local clone with maybe a separate local branch).  Then, a
>>>>>> series of commits in that branch.  Git supports history  
>>>>>> rewriting, so
>>>>>> you can do things like push/pop commits and edit them.
>>>>>> guilt(git+quilt) can help, there are also other tools that are  
>>>>>> similiar.
>>>>>
>>>>> I'm a couple of days into using git locally and I like it so far.
>>>>> But there are a couple of things people should be aware of when  
>>>>> considering the switch:
>>>>> - The initial checkout takes a long time (+9 hours on my  
>>>>> machine) although it only ever has to be done once
>>>>
>>>> You can pick the revision to start your tracking at with the -r  
>>>> switch to avoid loading the entire project history.
>>>>
>>>>> - The learning curve is steeper than with svn
>>>>> - The workflows are quite different from svn so be prepared to  
>>>>> change the way you work
>>>>> - Setup on OS X can be a pain (you need XCode tools installed to  
>>>>> use the git-svn bridge and if you don't have your OS X install  
>>>>> DVD handy it's a 1GB download)
>>>>> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)
>>>>
>>>> Have you checked out "git gui" and GitX? http://gitx.frim.nl/
>>>>
>>>> I use git from the command line, so I'm not sure how well the  
>>>> "git gui" UI works, but GitX is pretty neat.
>>>
>>
>

[Anil Patel-3]

Yes, Its true, I have used my privileges to get free license for last two years but never really liked the tool enough to make it my primary IDE, always went back to Eclipse.

More recently Tim suggested this community edition thing and then Jacopo agreed that its much lighter and quicker, So I gave it one more shot. This time I like it.

So try community edition, it has everything you need to develop ofbiz.

Thanks and Regards
Anil Patel
HotWax Media Inc
http://www.hotwaxmedia.com/apache-ofbiz-blog/ofbiz-tutorial-custom-components-in-ofbiz/

On Dec 3, 2009, at 3:55 PM, Scott Gray wrote:

> BTW if memory serves you should be able to get a license for the full version for free via their open source program.
>
> Regards
> Scott
>
> On 4/12/2009, at 9:49 AM, Scott Gray wrote:
>
>> I did try it very briefly a few years back but I'm so used to Eclipse now that I'd be pretty reluctant to switch.  I will download it at some point though and take another look, thanks for the info.
>>
>> Regards
>> Scott
>>
>> On 4/12/2009, at 9:34 AM, Anil Patel wrote:
>>
>>> Scott, Have your tried IntelliJ,
>>>
>>> More recent release of IntelliJ Community edition has support for Git. In fact recently I have switched to using IntelliJ and I like it.
>>>
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> http://www.hotwaxmedia.com/apache-ofbiz-blog/ofbiz-tutorial-custom-components-in-ofbiz/
>>>
>>> On Dec 3, 2009, at 3:12 PM, Joe Eckard wrote:
>>>
>>>>
>>>> On Dec 3, 2009, at 2:50 PM, Scott Gray wrote:
>>>>
>>>>> On 4/12/2009, at 7:32 AM, Adam Heath wrote:
>>>>>
>>>>>> Scott Gray wrote:
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> When all of this comes across to the trunk could please consider
>>>>>>> separating it into at least two commits, one for the integration and
>>>>>>> another for all this other stuff.  It'll make the commits a little
>>>>>>> easier to read especially when people are looking at the commit history.
>>>>>>
>>>>>> As I've said countless times, git makes this easier.  You'd maintain a
>>>>>> branch(local clone with maybe a separate local branch).  Then, a
>>>>>> series of commits in that branch.  Git supports history rewriting, so
>>>>>> you can do things like push/pop commits and edit them.
>>>>>> guilt(git+quilt) can help, there are also other tools that are similiar.
>>>>>
>>>>> I'm a couple of days into using git locally and I like it so far.
>>>>> But there are a couple of things people should be aware of when considering the switch:
>>>>> - The initial checkout takes a long time (+9 hours on my machine) although it only ever has to be done once
>>>>
>>>> You can pick the revision to start your tracking at with the -r switch to avoid loading the entire project history.
>>>>
>>>>> - The learning curve is steeper than with svn
>>>>> - The workflows are quite different from svn so be prepared to change the way you work
>>>>> - Setup on OS X can be a pain (you need XCode tools installed to use the git-svn bridge and if you don't have your OS X install DVD handy it's a 1GB download)
>>>>> - GUI support is limited (e.g. the Eclipse plugin is at v0.6)
>>>>
>>>> Have you checked out "git gui" and GitX? http://gitx.frim.nl/
>>>>
>>>> I use git from the command line, so I'm not sure how well the "git gui" UI works, but GitX is pretty neat.
>>>
>>
>