Difference between revisions of "Dev:Source code"
From Synfig Studio :: Documentation
m (new bug tracker link) |
(Update to github repository) |
||
Line 4: | Line 4: | ||
*Using git (one repository) | *Using git (one repository) | ||
− | |||
Once you grab the code, you will need to follow the {{l|Dev:Build Instructions|build instructions}}. | Once you grab the code, you will need to follow the {{l|Dev:Build Instructions|build instructions}}. | ||
− | Commit notifications to master branch are sent to [http://cia.vc/stats/project/synfig CIA] and | + | Commit notifications to master branch are <strike>sent to [http://cia.vc/stats/project/synfig CIA] and</strike> shown up in the {{l|Contact|IRC channel}}. |
While you are browsing the code, you may wish to refer to these links: | While you are browsing the code, you may wish to refer to these links: | ||
Line 22: | Line 21: | ||
* {{l|Interesting Readings}} | * {{l|Interesting Readings}} | ||
− | == GIT repository at | + | == GIT repository at Github== |
Anonymous access: | Anonymous access: | ||
− | git clone git:// | + | git clone git://github.com/synfig/synfig.git |
People with commit access should use this command instead: | People with commit access should use this command instead: | ||
− | git clone | + | git clone git@github.com:synfig/synfig.git |
+ | Or this one if you prefer https protocol: | ||
+ | git clone https://github.com/synfig/synfig.git | ||
− | You can also check out the [ | + | You can also check out the [https://github.com/synfig/synfig web interface] to that repository. |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
+ | Check out [https://help.github.com Github help page] for further references. | ||
==Proposed workflow and other repositories == | ==Proposed workflow and other repositories == | ||
Line 68: | Line 48: | ||
* If it is possible, rebase & rework branches to keep history more sane, linear and atomic. | * If it is possible, rebase & rework branches to keep history more sane, linear and atomic. | ||
* Releases are tagged according to following criteria: | * Releases are tagged according to following criteria: | ||
− | ** If the release consist on a few trivial set of features or bug fixes then increase the third numeration level: 0. | + | ** If the release consist on a few trivial set of features or bug fixes then increase the third numeration level: 0.64.0 -> 0.64.1 |
− | ** If the release consist on a set of important features and/or includes non backward compatible file format, then increase the second level numeration: 0. | + | ** If the release consist on a set of important features and/or includes non backward compatible file format, then increase the second level numeration: 0.64.1 -> 0.65.0 |
− | Proposed set of git repositories: | + | Proposed set of git repositories (this section is outdated): |
* admin.git - gitosis admin settings - holds groups, repos and users | * admin.git - gitosis admin settings - holds groups, repos and users |
Revision as of 19:38, 10 May 2013
Hey you! Do you want access to bleeding-edge Synfig? Well, I have good news. We provide a way to get the code:
- Using git (one repository)
Once you grab the code, you will need to follow the build instructions.
Commit notifications to master branch are sent to CIA and shown up in the IRC channel.
While you are browsing the code, you may wish to refer to these links:
- Bug tracker
- API documentation
- source code outline
- source code glossary
- ETL make check failures
- Mapping between layer types, classes and .cpp files
- ValueNode types
- Blend Method enumeration values
- Interesting Readings
GIT repository at Github
Anonymous access:
git clone git://github.com/synfig/synfig.git
People with commit access should use this command instead:
git clone git@github.com:synfig/synfig.git
Or this one if you prefer https protocol:
git clone https://github.com/synfig/synfig.git
You can also check out the web interface to that repository.
Check out Github help page for further references.
Proposed workflow and other repositories
Proposed git workflow:
- Consider the master branch the stable one.
- Each coder should have a username_master branch where all the small changes are done.
- Once the username_master branch is considered stable it can be rebased/merged to master.
- Work on new non-trivial features/fixes on username_feature branches.
- Once the username_feature branch is considered stable it can be rebased/merged to master.
- Obviously commit trivial fixes straight to the master.
- If it is possible, rebase & rework branches to keep history more sane, linear and atomic.
- Releases are tagged according to following criteria:
- If the release consist on a few trivial set of features or bug fixes then increase the third numeration level: 0.64.0 -> 0.64.1
- If the release consist on a set of important features and/or includes non backward compatible file format, then increase the second level numeration: 0.64.1 -> 0.65.0
Proposed set of git repositories (this section is outdated):
- admin.git - gitosis admin settings - holds groups, repos and users
- code/* - direct conversions from SVN
- code/ETL.git - ETL
- code/synfig.git - synfig
- code/synfigstudio.git - synfigstudio
- pkg/* - bits for various packaging systems
- pkg/windows.git - Windows packaging (needs separating from the code repos)
- pkg/macos.git - MacOS packaging (needs separating from the code repos)
- pkg/jhbuild.git - JHBuild moduleset (needs writing)
- pkg/autopackage.git - Autopackage bits (needs writing)
- web/* - various bits used to maintain the website
- web/skin.git - skin for the website
- web/content.git - content for the website (pending switch to ikiwiki)
- misc/* - various stuff needed
- misc/svn2git.git - the scripts used to convert the SVN repo to git