VirtueMart - 1.1 Developer's Guide
Documentation Sources
30
Important
Before you run the scripts make sure that 7Zip is installed on your computer.
1. Configure the scripts!
First you must open the files and change the paths inside to match your configuration.
2. Build your own packages by running the script:
• Build_Component.bat - (Win) build just the component archive
• Build_VirtueMart_complete.bat - (Win) build the whole “Complete Package” including modules
and mambots
• build_component.sh - (Linux) build the component archive
• build_virtuemart_complete.sh - (Linux) build the whole “Complete Package” including modules
and mambots
5.3.2. Documentation Sources
The VirtueMart Project manages the documentation in the DocBook [http://docbook.org] format. You
can checkout the sources in the DocBook format and transform the DocBook source using an XSL
Transformer into PDF, HTML, CHM or whatever else... All you have to do is checkout the directory
can checkout the sources in the DocBook format and transform the DocBook source using an XSL
Transformer into PDF, HTML, CHM or whatever else... All you have to do is checkout the directory
/trunk/documentation
from dev.virtuemart.net (details see above).
The easiest and most professional software to modify DocBook sources is the XML Mind XML
Editor [http://xmlmind.com/xmleditor/download.shtml]. After you have downloaded and installed the
software you can just open the main documentation file and start working on it:
Editor [http://xmlmind.com/xmleditor/download.shtml]. After you have downloaded and installed the
software you can just open the main documentation file and start working on it:
• /trunk/documentation/User_Manual/User_Manual.xml (the User Manual)
• /trunk/documentation/Developer_Manual/Developer_Manual.xml (the Developer Manual)
5.4. Using SVN
5.4.1. Basic points
This section describes things that are generally applicable when using SVN; guidelines that are more
specific to particular tasks or uses are described in the other sections.
specific to particular tasks or uses are described in the other sections.
5.4.1.1. When to check in
Check in early, check in often. When you have made a change that works, check it in. Check in
separate changes in separate commits (as much as possible). Don't be shy to check in work-in-progress,
so long as it is minimally functional, or at least compilable without errors.
separate changes in separate commits (as much as possible). Don't be shy to check in work-in-progress,
so long as it is minimally functional, or at least compilable without errors.
5.4.1.2. Commit messages
Use meaningful commit messages. Explain what bug the commit fixes, or what features it adds. Don't
be too concise: "fixed typo" is too short; "fixed Task# 2432" or "fixed typo in function name" is OK.
The aim is to make it easier to find the desired change easily from just the commit messages.
be too concise: "fixed typo" is too short; "fixed Task# 2432" or "fixed typo in function name" is OK.
The aim is to make it easier to find the desired change easily from just the commit messages.
The converse of this is including too much information. SVN automatically maintains information
like the date and time of the commit, who made the commit, what code was changed, etc. You don't
need to include it in the commit message yourself.
like the date and time of the commit, who made the commit, what code was changed, etc. You don't
need to include it in the commit message yourself.