Vtiger CRM CVS Repository Access
From vtiger.com
[edit] Download
If you want to download the svn version(latest of the latest), execute:
svn checkout http://trac.vtiger.com/svn/vtiger/vtigercrm/trunk/
[edit] Contribute
We are developers and these are some pointers on working with the code so that we can work well together. If you feel that there can be some other instructions added, feel free.
Our only intention is to keep it simple!
1. Join the Community
- We prefer patches and discussions being held on the mailing list(s), not sent to individuals.
- The mailing lists for patch contribution is vtigercrm-contributors
2. Coding Standard
- Naming
- Try using a non-confusing naming scheme for your new functions and variable names. It doesn't necessarily have to mean that you should use the same as in other places of the code, just that the names should be logical, understandable and be named according to what they're used for.
- Indenting
- Please try using the same indenting levels and bracing method as all the other code already does. It makes the source code a lot easier to follow if all of it is written using the same style.
- Commenting
- Comment your source code extensively using C comments (/* comment */ ). Commented code is quality code and enables future modifications much more. Please note that others will build on top of your code. Hence, the need to understand your code is paramount. So code properly and also never forget to write appropriate comments. The comments need not be cryptic but neither should they be too verbose.
- General Style
- Keep your functions small. If they're small you avoid a lot of mistakes and you don't accidentally mix up variables etc.
- Non-clobbering All Over
- When you write new functionality or fix bugs, it is important that you don't fiddle all over the source files and functions. Remember that it is likely that other people have done changes in the same source files as you have and possibly even in the same functions. If you bring completely new functionality, try writing it in a new source file. If you fix bugs, try to fix one bug at a time and send them as separate patches.
3. Separate Patches
- All fixes that correct different problems should be in their own patch with an attached description exactly what they correct so that all patches can be selectively applied by the maintainer or other interested parties. Please try to get the latest available sources to make your patches against. It makes the life of the developers so much easier.
- Well-described, easy-to-apply patches are a pleasure for a developer to receive and go a long way towards making the product more stable and powerful, so thank you in advance for contributing them!
- Making a patch available and accepting it
- Send it as a MIME attachment to the proper mailing list. Someone will review it and post the feedbacks if any. If all goes well, the same will be integrated and you will be notified about the same. Your name will also be acknowledged among the contributors.
4. Document
- We need documents to work with things. Documentation is considered a pain, but then, a little pain goes a long way in solving bigger issues.
5. Write Access to SVN Repository
- If you are a frequent contributor or have another good reason, you can of course get write access to the SVN repository and then you'll be able to check-in all your changes straight into the SVN tree instead of sending all changes by mail as patches. Just ask if this is what you'd want. You will be required to have posted a few quality patches first, before you can be granted write access.
6. Test Cases
- Every feature that is added should get at least one valid test case that verifies that it works as documented. If every submitter also posts a few test cases, it won't end up as a heavy burden on a single person! Currently there is no separate folder for the same.
- Notifications of any changes to Issue Tracking, as well as SVN checkins, are automatically sent to the appropriate bug and SVN mailing lists
- If you see a question in the forum or mail list where you (might) know the answer: Please answer it! We also ask questions in the forums and appreciate help!
- Something is not there and you really need it. Please ask, what you can do to to fix it via a support request. If you did it, let us know!
- If a new release or patch comes out: Please install and test it!
- Help with translation. Please use the language packs and follow the instructions in the forum. Test the product. If there be an issue , report it and someone will get back to you.
7. Mailing Lists
- We have setup the following Mailing Lists for the convenience of users posting the messages in appropriate Mailing List (please replace "l.v.c" with lists.vtigercrm.com):
- vtigercrm-developers@l.v.c