Boris Kocherov
2009-02-23 13:30:03 UTC
As far as ERP5 development is predominantly done by Nexedi and i am an
external developer, the suggestions offered in this letter could be
evaluated as unsuitable by Nexedi staff. Nevertheless i state this
topics because i suppose even their discussion is useful for the
project.
The patches' examples are submitted in this letter only for the
illustration purposes and under no circumstances have any evaluating
sense against their authors.
One change of the code should be done by one patch, not by many patches.
The breach of that principle lead to difficulties in patch' reverse and
loss in changes' history. However it could not be maintained under
existent development method:
https://www.raskon.org/hg/svn.erp5.org/erp5/trunk/rev/48a725354065
https://www.raskon.org/hg/svn.erp5.org/erp5/trunk/rev/0740f359c0c5
https://www.raskon.org/hg/svn.erp5.org/erp5/trunk/rev/19574d3f3009
As i understand, currently changes are commited to svn before they go
through the unit tests. Furthermore there is no other possibility to
know how your changes pass the unit tests except by commiting them. Thus
the debugging time increase and some garbage fall into svn. It would be
better to prepare changes locally, test them on different computers,
send them by email to the server which would execute unit testes and
after that operations commit changes to general branch. In this case we
can get another problem ? bt/revisin files can conflict if other
developer have made his changes to the same business template during the
debugging period. To solve this problem we should not use the current
procedure of changing bt/revision and use the ?revision number? from svn
repository instead. For mercurial I've wrote the extension which update
bt/revision files automatically. As the mercurial revision number is
string this change demands modifications in products/ERP5. Such hook can
be done for any Revision Control System (SVN, GIT). This approach should
ultimately increase efficiency and quality of development.
If the developer use his own zope server (i think it's logical and
convenient) then there is no need to change erp5_forge.bt5 for applying
above mentioned development procedure. It's better to use standard
facilities of Revision Control System for commit, revert... because they
are more powerful. This patch
https://www.raskon.org/hg/raskon/patches//file/9cef1cc87394/bt5_BusinessTemplateFolder_not_clean_local_folder.patch
speeds up the export procedure because the unchanged files are not
rewritten and as a result the filesystem cache is used more effectively.
My work in this direction could be found here:
https://www.raskon.org/hg/raskon/patches.
Regards,
Boris Kocherov
--
Crisis had come unexpectedly, just as winter comes unexpectedly to
Russia every year.
external developer, the suggestions offered in this letter could be
evaluated as unsuitable by Nexedi staff. Nevertheless i state this
topics because i suppose even their discussion is useful for the
project.
The patches' examples are submitted in this letter only for the
illustration purposes and under no circumstances have any evaluating
sense against their authors.
One change of the code should be done by one patch, not by many patches.
The breach of that principle lead to difficulties in patch' reverse and
loss in changes' history. However it could not be maintained under
existent development method:
https://www.raskon.org/hg/svn.erp5.org/erp5/trunk/rev/48a725354065
https://www.raskon.org/hg/svn.erp5.org/erp5/trunk/rev/0740f359c0c5
https://www.raskon.org/hg/svn.erp5.org/erp5/trunk/rev/19574d3f3009
As i understand, currently changes are commited to svn before they go
through the unit tests. Furthermore there is no other possibility to
know how your changes pass the unit tests except by commiting them. Thus
the debugging time increase and some garbage fall into svn. It would be
better to prepare changes locally, test them on different computers,
send them by email to the server which would execute unit testes and
after that operations commit changes to general branch. In this case we
can get another problem ? bt/revisin files can conflict if other
developer have made his changes to the same business template during the
debugging period. To solve this problem we should not use the current
procedure of changing bt/revision and use the ?revision number? from svn
repository instead. For mercurial I've wrote the extension which update
bt/revision files automatically. As the mercurial revision number is
string this change demands modifications in products/ERP5. Such hook can
be done for any Revision Control System (SVN, GIT). This approach should
ultimately increase efficiency and quality of development.
If the developer use his own zope server (i think it's logical and
convenient) then there is no need to change erp5_forge.bt5 for applying
above mentioned development procedure. It's better to use standard
facilities of Revision Control System for commit, revert... because they
are more powerful. This patch
https://www.raskon.org/hg/raskon/patches//file/9cef1cc87394/bt5_BusinessTemplateFolder_not_clean_local_folder.patch
speeds up the export procedure because the unchanged files are not
rewritten and as a result the filesystem cache is used more effectively.
My work in this direction could be found here:
https://www.raskon.org/hg/raskon/patches.
Regards,
Boris Kocherov
--
Crisis had come unexpectedly, just as winter comes unexpectedly to
Russia every year.