Changes between Version 2 and Version 3 of WikiStart


Ignore:
Timestamp:
Mar 3, 2010, 9:23:29 PM (14 years ago)
Author:
ydario
Comment:

Added coding guidelines.

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v2 v3  
    2626
    2727The final goal of the first part of the project is to make every Windows program load and operate properly, and the goal of the second part of the project is to create complete OS/2 implementation of Win32 API, which means that every single API function should be implemented or mapped to equivalent OS/2 API function via Odin32. Whether those goals will be ever achieved remains to be seen, but this project gives good results even now, since no Windows program uses all API functions and very few use even majority of them.
     28
     29
     30== About Trac&Subversion, code guidelines ==
     31
     32To allow proper coding and usage of Trac&Subversion features, it is suggested to follow some guidelines.
     33
     34First, all commits must belong to a ticket; tickets can be created by project manager or by developers for defect fixing, code enhancements or other tasks.
     35
     36Tickets will be used to tell other people about problems, and allow discussion of patches or new code added.
     37Subversion commits needs to link their ticket in commit message. This can be done using the following syntax:
     38
     39{{{
     40   svn commit -m "Here are my changes. ticket:1." *.*
     41}}}
     42
     43Trac timeline will automagically convert 'ticket:1' into the URL of the ticket.
     44
     45At the same time, the changeset number should be added to the ticket using the following syntax:
     46
     47{{{
     48   (changeset:145) Here are my changes.
     49}}}
     50
     51This allows following ticket life without looking at timeline changes every time. While the commit message is usually short, developers can add more detailed informations in ticket record. Remember, other developers could not know what you are doing, or understand what has been changed simply looking at code.
     52
     53Also we need to track changes to avoid regressions as much as possible: exhaustive descriptions makes life much easier when regressions or typos must be fixed.