Last modified 3 weeks ago
Last modified on 04/27/13 00:21:07
Basics
Our git repository is currently at github.
- branch master
- We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
- branch develop
- We consider origin/develop to be the main branch where the source code of HEAD always
reflects a state with the latest delivered development changes for the next release.
Some would call this the “integration branch”.
This is where any automatic nightly builds are built from.
Please read Development/WorkflowBranchingMergingTagging and Development/CommitMessages.
More information to come here.
Guidlines for commits
- Commit often and in logical chunks
A commit should be one (and just one) logical unit. It should be something that someone might want to patch or revert in its entirety, and never piecewise. If it could be useful in pieces, make separate commits.
- Write meaningful commit messages.
Using atomic commits will result in short, clear, and concise commit messages. Non-atomic commits make for awful run-on commit messages.
- Try to make small patches (i.e. work in consistent increments).
- Separate changes that affect functionality from those that just affect code layout, indendation, whitespace, filenames etc. This means that when looking at patches later, we don't have to wade through loads of non-functional changes to get to the important parts of the patch.
- Especially don't mix different types of change, and put a standard prefix for each type of change to identify it in your commit message.
- Restrict all whitespace changes to a specific type and document as such.
- Restrict refactorings (that should not change functionality) to their own commit (and document).
- Restrict functionality changes (bug fix or new feature) to their own changelists (and document).
- If possible, commit often. This helps to avoid conflicts.
- Only push when your tree passes validation: see TestingPatches?.
- Discuss anything you think might be controversial before pushing it.
Other Development Documentation
Useful Links
Python
- PEP 273 -- Import Modules from Zip Archives
- PEP 302 -- New Import Hooks
- -- Example of New Import Hooks Usage
- Unofficial Windows Binaries for Python Extension Packages
- Hidden Features of Python
- Introduction to pip and virtualenv
- pythonz: a Python installation manager
Python Distributions
C/C++
- Python/C API Reference Manual
- Crossplatform filepath naming
- wchar_t on Win/Lin/Osx
- http://stackoverflow.com/questions/4130180/how-to-use-vs-c-getenvironmentvariable-as-cleanly-as-possible
- What is LPCSTR, LPCTSTR and LPTSTR
- Shell Path Handling Functions win32
- Test macros like _POSIX_C_SOURCE, _GNU_SOURCE, _XOPEN_SOURCE
Operating Systems
General
Windows
Temporary Files
- Creating temporary files on win32 part 1
- Creating temporary files on win32 part 2
- Unique temporary directory in c on Win
Mac OS X
- Dynamic Libraries, RPATH, and Mac OS
- RPATH blog entry
- Building with shared libs
- Dynamic Library Usage Guidelines - Apple doc
- Linking on Darwin (OS X)
- Mach-O File Format Reference
- visual Mach-O file browser - MachOView
- Some C++ Tips and Tricks for Mac OS X
