UUIDs in Openbravo ERP r2.50

UUID project branch has been merged with r2.50 branch.

Continue reading


Reintegrating multiple branches to trunk

I have some doubts about how to merge back to trunk the following case: I have a project branch that is already reintegrated in the trunk and another branch that started from the first one, the problem is how to reintegrate it to the trunk.

Continue reading

Merging with subversion 1.5

Some weeks ago Openbravo subversion repository was upgraded to version 1.5.

The greatest feature this new version has is the merge tracking. From now on it is not necessary to manually have into account the revisions that have already been merged between branches.

Now merging is as easy as:

myWCbranch$ svn merge https://dev.openbravo.com/svn/openbravo/trunk

This command will merge all the not already merged changes in trunk to my branch working copy. And now the best part: when I’ve finished with by branch, to merge it back to the trunk this command will do all the work:

myWCtrunk$ svn merge --reintegrate https://dev.openbravo.com/svn/openbravo/myBranch

I hope this will save us a lot of headhaches…

There is a new feature personally I don’t like is the the interactive conflict resolution, specially when merging big projects it is annoying to have to manually decide about each conflict while the process has not been finished yet. It is possible to deactivate it editing the .subversion/config file to add in the [miscellany] section the following line:

interactive-conflicts = no

There is some documentation about branches and merges in the Openbravo wiki.

Openbravo ERP r2.50 provisional branch

In this post I will introduce some guidelines and recommendations on how to manage the source code branches for Openbravo R2.40 and R.250.

Currently trunk is used for bug fixing for r2.40 until r2.40 stable version is released.

A branch for r2.50 developments was created from trunk and will be merged back to trunk once r2.40 stable is released. Periodically r2.50 branch will be updated with trunk to take there the bug fixed in trunk.

Taking all this into account the way of working should be:

  • Bug fixing: Only commit to trunk, it is not necessary to do it to r2.50 because these commits will be merged periodically, in case you want to commit the fix also to r2.50 do it via merge: do not make different commits in both sides (which could cause conflicts).
  • New r2.50 developments: Create a branch for the project from r2.50 branch. Once the project is finished merge it back (reintegrate) to r2.50 branch, in case when the project is finish r2.40 stable is released the merge back will go to trunk.