svn commit: r930729 - in /ofbiz/branches/executioncontext20091231: ./ applications/accounting/ applications/accounting/config/ applications/accounting/data/ applications/accounting/data/helpdata/ applications/accounting/documents/ applications/accounti...

[ad...@apache.org]

Author: adrianc
Date: Sun Apr  4 18:08:58 2010
New Revision: 930729

URL: http://svn.apache.org/viewvc?rev=930729&view=rev
Log:
Synchronized branch with trunk. Sorry for the huge commit - I tried to merge only the folders I was interested in, but there were too many cross-dependencies.


[This commit notification would consist of 80 parts, 
which exceeds the limit of 50 ones, so it was shortened to the summary.]

Re: svn commit: r930729 - in /ofbiz/branches/executioncontext20091231: ./ applications/accounting/ applications/accounting/config/ applications/accounting/data/ applications/accounting/data/helpdata/ applications/accounting/documents/ applications/accounti...

[Adrian Crum <ad...@yahoo.com>]

--- On Sun, 4/4/10, Adam Heath <do...@brainfood.com> wrote:
> adrianc@apache.org
> wrote:
> > Author: adrianc
> > Date: Sun Apr  4 18:08:58 2010
> > New Revision: 930729
> > 
> > URL: http://svn.apache.org/viewvc?rev=930729&view=rev
> > Log:
> > Synchronized branch with trunk. Sorry for the huge
> commit - I tried to merge only the folders I was interested
> in, but there were too many cross-dependencies.
> > 
> > 
> > [This commit notification would consist of 80 parts, 
> > which exceeds the limit of 50 ones, so it was
> shortened to the summary.]
> 
> This is where git rebase would be better.  Instead of
> a single,
> friggin huge commit, that contains a flattened view of
> everything else
> that has happened in another development tree, rebase would
> reply all
> the changes in this branch, on top of the other tree. 
> This keeps the
> history cleaner, as you don't have to deal with these merge
> commits
> going forward.
> 
> rebase is also smart enough, so that if some new branch
> gets slowly
> commited to trunk, the rebase will end up removing that
> particular
> commit during the branch's rebase.

I will look into using git, *after* I get the new security redesign merged into the trunk, and I get the Commons Convert project on its way, and...

;-)



      

Re: svn commit: r930729 - in /ofbiz/branches/executioncontext20091231: ./ applications/accounting/ applications/accounting/config/ applications/accounting/data/ applications/accounting/data/helpdata/ applications/accounting/documents/ applications/accounti...

[Adam Heath <do...@brainfood.com>]

adrianc@apache.org wrote:
> Author: adrianc
> Date: Sun Apr  4 18:08:58 2010
> New Revision: 930729
> 
> URL: http://svn.apache.org/viewvc?rev=930729&view=rev
> Log:
> Synchronized branch with trunk. Sorry for the huge commit - I tried to merge only the folders I was interested in, but there were too many cross-dependencies.
> 
> 
> [This commit notification would consist of 80 parts, 
> which exceeds the limit of 50 ones, so it was shortened to the summary.]

This is where git rebase would be better.  Instead of a single,
friggin huge commit, that contains a flattened view of everything else
that has happened in another development tree, rebase would reply all
the changes in this branch, on top of the other tree.  This keeps the
history cleaner, as you don't have to deal with these merge commits
going forward.

rebase is also smart enough, so that if some new branch gets slowly
commited to trunk, the rebase will end up removing that particular
commit during the branch's rebase.