1.1 Clients and tools for Subversion
- Subclipse (Plugin for Eclipse IDE, cross platform)
- TortoiseSVN (Windows)
- Subversive (Plugin for Eclipse IDE, cross platform)
- Subversion Command Line Client (Linux, Mac OS X, Windows)
1.2 SVN location
- Repository URL: https://adempiere.svn.sourceforge.net/svnroot/adempiere
- View on Browser: http://svn.sourceforge.net/viewvc/adempiere/
1.3 SVN structure
- branches/ - Use for development of major new features without disturbing the main line of development
- contributions/ - Initial and third party contributions
- trunk/ - Main line of development source goes here
- tags/ - Contains snapshots of the trunk at particular milestones, usually major releases or perhaps prior to a major departure in development
"One of the features of version control systems is the ability to isolate changes onto a separate line of development. This line is known as a branch. Branches are often used to try out new features without disturbing the main line of development with compiler errors and bugs. As soon as the new feature is stable enough then the development branch is merged back into the main branch (trunk)."
Patches should be posted to the SF Patch Tracker with sufficient information to identify their purpose. If a patch is supplied as a bug fix, it should reference the Bug Tracker ID (a bug report should be made if none already exists) and a note should be appended to the bug report directing to the patch.
The patch should meet the conventions for code layout and documentation specified elsewhere (TODO).
Patches should be atomic, that is, they should make the minimum changes required to fix a specific problem or implement a specific feature. Combining multiple fixes into one patch simply makes code review more difficult.
The patch manager (position to be created) will then forward the patch to a developer with commit access to the relevant project area for review and implementation. Alternatively, interested committers can claim the patch.
See also Sending Patches.
SVN Commit Access
Commit access can be gained by being sponsored by an existing committer. Generally the proposed developer will have submitted some number (?) of substantial and effective patches. The proposal will be made in the relevant forum (to be created) and executed on the basis of some majority agreement from existing committers within a certain timeframe (eg +2 votes within 1 week).
Commit access can be partial or full, with partial meaning access is only granted to some subprojects within the committer's field. All tool/plugin contributers will automatically receive partial commit access to maintain their own tool/plugin.
Commit access can be rescinded under certain circumstances: malicious commits, committing without peer review. Some procedure will need to be established to ensure this is conducted fairly.
All commits must be peer reviewed unless they are obvious. "Obvious" includes syntax errors, commenting, spelling and grammar mistakes. Commits must be accompanied by a log message, describing the purpose of the commit (including bug reference), the committer, the original contributors, and the name of another committer who seconds the commit. The seconder is considered equally responsible for the commit, and blame for any errors will be shared, so it is in their interest to review any code thoroughly before signing off on it.
- PostgreSQL Porting from Oracle PL/SQL
- How to call Stored Procedures from JasperReports
- Oracle Database Error Code (ORA-xxxxx)